On Mon, Jun 17, 2019 at 8:53 PM Kevin Fenzi <ke...@scrye.com> wrote: > > 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. > 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? >
And that comes down to people shouldn't need to have to think about these things when working in Rawhide. While I don't disagree that Rawhide should be usable, I fundamentally disagree with making it harder for people to put things in Rawhide. We should be developing our tooling to make it _easier_ for stuff to go into Rawhide, and have Rawhide fix itself when the issues are relatively trivial to fix (such as reverse dependency rebuilding). > > 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. > Side tags will happen a lot more often because the tooling is pushing us to do it that way. Don't discount the potential for future insanity. I'm still not sure side-tags are enough. Could we have a concept of a "scratch side tag"? Something like a scratch build, but contains a collection of builds and creates an overlay repo that can be used to run checks on for auto-merging? If they're good, then it would get auto-built properly into the main rawhide tag (or even stable tag!). -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
