|
Dne 18. 06. 19 v 2:03 Kevin Fenzi
napsal(a):
On 6/17/19 4:47 PM, Kevin Kofler wrote:Kevin Fenzi wrote:I disagree. I think we need gating to block as much stuff that breaks things from landing as we can and then we should find that keeping composes going is much easier on all of us. Then things can be fixed when gating catches them and it's on the person who broke things.And that is going to make development completely cringe to a halt. It is the nature of a distribution branch under development that things will sometimes be completely broken for a couple weeks. There needs to be a place to do development that can cause such temporary breakage.I again completely disagree. There is no reason for weeks of breakage.
I think this has two sides. While you say there is not reason for weeks of breakage, the broken compose means that my Rawhide can't be updated and it might be broken for weeks. E.g. last Rawhide compose succeeded on 9th of June. If at least the Rawhide repository was updated, I would probably notice the breakage. Also, while we are informed about successful composes, there is unfortunately no information about broken composes. I know, I was pointed several times to some repositories with some tickets or what not, but that is hardly useful.
Vít
Most of the issues that break composes are unannounced abi bumps where just rebuilding dependent packages fixes it. Or broken deps (likewise). Or mistakes made in kickstarts/comps. Or something that doesn't even run. What good does having everyone broken for weeks do?The side tag approach already does not scale, as evidenced by this thread.It does. You just need to communicate with others working in the same area, IMHO. I don't think we need some technical thing for something that happens rarely and can be solved by more communication. kevin |
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
