----- Original Message ----- > From: "Miro Hrončok" <mhroncok@xxxxxxxxxx> > To: devel@xxxxxxxxxxxxxxxxxxxxxxx > Sent: Wednesday, August 14, 2019 7:43:13 PM > Subject: Re: Let's revisit the FTBFS policy > > On 14. 08. 19 19:22, Ben Cotton wrote: > > I want to publicly express my appreciation for Miro's efforts to > > enforce our policy and his willingness to take the hits from people > > being rightly upset at its flaws. I also appreciate that the community > > has done a good job of understanding that the policy is the problem > > and not making it a personal attack on Miro. > > Thanks. Support like this is greatly appreciated. > > > On Wed, Aug 14, 2019 at 12:24 PM Jason L Tibbitts III <tibbs@xxxxxxxxxxx> > > wrote: > >> > >>>>>>> "MH" == Miro Hrončok <mhroncok@xxxxxxxxxx> writes: > >> > >> MH> If we stop here, the current "setting to ASSIGNED to stop this" > >> MH> remains a problem. > >> > >> Let's think about why this is perceived as a problem. The maintainer > >> has performed an affirmative act that shows they noticed. Can't we just > >> accept that as some statement of intent and stop bugging them at that > >> point? > > > > This is a reasonable compromise to make, IMO. In a perfect world, we'd > > have enough active packagers to handle things in a timely manner. But > > in this world, people have a lot going on and there's only so much we > > can do. People setting a bug to ASSIGNED is a problem I'm willing to > > accept. If there's an exceptional case, we can say FESCo has the > > ability to step in and remove it. We should assume positive intent > > with maintainers and trust that they're doing the right thing. > > What if... we only allow swaying FTBFS bugs under the carpet for a certain > period of time? > > E.g. > > 1. Mass rebuild for Fedora N happens > 2. Packages that fail to build get open bugzillas > 3. Packages with NEW bugizllas are orphaned after 8 weeks with weekly > reminders > 4. If the package hasn't rebuilt for a certain number of releases, it is > flagged for removal despite the bug status. > > Of course the removal would still need to be communicated properly, but I > suspect only a couple of packages would fall into that category. > > I suppose that at a time of a release of Fedora version, all shipped packages > should have been rebuilt on a platform that was supported on the time of the > release. > > E.g. when we release Fedora 32, Fedora 28 is already EOL for 5 months. It is > IMHO reasonable to expect the packages were rebuilt at least on Fedora 29. > > That would effectively mean: > > 0. package built with .fc29 release tag before the mass rebuild > 1. Fedora 29 mass rebuild, package FTBFS, is ASSIGNED, nothing happens > 2. Fedora 30 mass rebuild, package FTBFS, is ASSIGNED, nothing happens > 3. Fedora 31 mass rebuild, package FTBFS, is ASSIGNED, kind warning > 4. Fedora 32 mass rebuild, package FTBFS, is ASSIGNED, big fat warning > 5. Fedora 32 branches, package still fails to build, we retire it > > Or: > > 0. package built with .fc28 release tag before F28 branching > 1. Fedora 29 mass rebuild, package FTBFS, is ASSIGNED, nothing happens > 2. Fedora 30 mass rebuild, package FTBFS, is ASSIGNED, kind warning > 3. Fedora 31 mass rebuild, package FTBFS, is ASSIGNED, big fat warning > 4. Fedora 31 branches, package still fails to build, we retire it > > That gives 1.5 years minimum (F28 branching to F31 branching) to fix a FTBFS. > Is > that reasonable? > > (With a possibility to request an exception in exceptional cases.) > > The policy is also easy enough to define: > > "Rawhide packages with latest successful build made in Fedora N are retired > from > master after Fedora N+3 branches." Yes, that sounds great! Thanks for communicating this, Pavel > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > _______________________________________________ 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
