On Wed, 2019-08-14 at 14:55 +0200, Vít Ondruch wrote: > Dne 14. 08. 19 v 14:23 Miro Hrončok napsal(a): > > Hello. > > > > Recently, a couple hundred packages were retired from rawhide (Fedora > > 31 at that time) based on the Fedora Failed to Build From Source > > Policy [1]. From various reactions over several threads it seems this > > policy is not ideal. This is an attempt to collect feedback and make > > the policy better serve Fedora's needs. > > > > Fedora has a policy for a long time that can be simplified as: > > > > 1. Mass rebuild for Fedora N happens by releng > > 2. Packages that fail to build get open bugzillas by releng > > 3. Packages with NEW bugizllas are orphaned after 8 weeks with weekly > > reminders by releng > > I think it would be probably enough to stop here. Orphaned packages gets > garbage collected ATM. The step 4 was a bit unexpected for packages with > bugs in ASSIGNED state especially. > > Also the timing with mass rebuild and shifting packages from Rawhide to > F31 is unfortunate. I saw a lot of packages, which were reported as > FTBFS in BZ, then they were retired but later the bugs were moved from > Rawhide to F31, that was strange. While not directly policy related, I strongly suggest, if possible, to do a test compose with the packages removed to see how it fares & ideally run some tests (Open QA ?) on the result, to prevent avoidable breakage. Droping such big batches of packages without testing we can still produce out blocking deliverables & checking the deliverables appear to work simply seems too invasive to me. > > > Vít > > > > 4. A week before Fedora N+1 branching any packages which still have > > open Fedora N FTBFS bug are retired by releng > > > > However, 3 or 4 haven't happened since Fedora ~26, because the > > automation was not working any more for various reasons I don't > > understand. > > > > The policy was then updated by FESCo to allow anybody to step up and > > do 3. manually. > > However it needs 2 e-mails to devel directed at the package owners and > > that may be understood as a personal attack by some. > > So nobody ever did that but me (twice) IIRC (and I got my share of > > shame for that). > > > > Currently, the FTBFS retirement is problematic due to various things: > > > > 1) Bugzilla spam: Maintainers are spammed weekly by releng, some of > > them find that annoying and simply switch the bug to ASSIGNED to make > > it stop. > > > > The problem is, how do we both keep notifying the maintainers that > > action is needed and not spam them with stuff that will make them > > filter all Fedora e-mails to /dev/null. > > > > 2) Retirement out of the blue. When releng executes 4., packagers that > > stopped the bugzilla spam by setting the bug to ASSIGNED are suddenly > > surprised the package was retired. OTOH arguably they made a > > deliberate action to stop the notifications. However, most > > importantly, any dependent packages were not notified at all, which is > > **not fair**. > > > > This state is broken mostly because there is no automatic orphaning of > > packages that have NEW bugzillas and there is no orphaning at all for > > packages where the bugzillas are ASSIGNED for months. For the second > > bit, everything indicates that packagers are aware of the problem and > > will fix the bug in time before 4., but they don't and things blow up. > > > > 3) Questionable importance of the FTBFS bug. > > > > Repeatedly, it has been stated by some, the FTBFS bug is not important > > and we should not retire packages at all based on the fact that they > > "simply" fail to build. I personally don't agree with this for various > > reasons, but I can imagine a situation, where it is reasonable to say > > so and delay the problem. Obvious argument is: Better to have 1 > > package nonbuildable than have 100 packages nonisntallable. So we need > > a way to opt-out from the retirement, however simply setting the > > bugzilla to ASSIGNED is not it, because we will end up with packages > > last built 6 years ago (and I believe this is not what we want). > > > > > > I'm starting this thread to collect the ideas about how to make this > > better. > > If you see more problems, share them. I promise I'll do my best to > > make the policy work better for both Fedora and the people who make > > Fedora. > > > > [1] > > https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ > > > > > _______________________________________________ > 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 _______________________________________________ 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
