Re: RFC: Multiple parallel side tags

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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


_______________________________________________
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

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux