Let's revisit the FTBFS policy

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

 



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 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/


--
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




[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