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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Reply via email to