Dne 14. 08. 19 v 19:43 Miro Hrončok napsal(a): > 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." > Well, really, I don't see the ASSIGNED as that big deal. That at least means the maintainer is alive and paying (some) attention and that is important. In the end, you can't prevent such maintainer to unretire the FTBFS package and tag it back into Fedora. Also, in my case "rubygems" package was retired. The interesting part here is that the binary package build from "rubygems" SRPM was not even part of compose, so some of the proposals to remove such packages from compose would not apply here. Now you might wonder why we had "rubygems" package in Fedora. Partly, it is historic reason. It used to be independent project you probably wanted to install alongside Ruby. As the time goes, the RubyGems were bundled into Ruby. So now "ruby" package provides "rubygems" package. But RubyGems are still doing independent releases out of Ruby schedule. So the "rubygems" package gives us easy way to update RubyGems in Ruby without updating Ruby itself and adding some additional sources etc. There was no reason to do this in more than year, that's why I did not bother to fix the FTBFS. Now the package is retired. Of course you might consider this special case, but apparently all the other people who speak up had different special cases. Vít _______________________________________________ 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
