Re: Let's revisit the FTBFS policy

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

 



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.


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




[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