I see your point, I am a part of the Quality Assurance team here.
+1 Making it easier on package maintainers
+1 On retiring all i686 (32 Bit Systems)
On Wed, 17 Nov 2021, 11:18 Fabio Valentini, <decatho...@gmail.com> wrote:
> On Wed, Nov 17, 2021 at 11:53 AM Zbigniew Jędrzejewski-Szmek
> <zbys...@in.waw.pl> wrote:
> >
> > On Tue, Nov 16, 2021 at 03:05:37PM -0500, Robbie Harwood wrote:
>
> (small snip)
>
> > > Is it really not? This seems the easiest way to go about it, honestly
> -
> > > just have it be permitted for maintainers to opt their stuff out of
> > > building on x86 and let the problem take care of itself recursively.
> >
> > Yeah, I think I'd go this way too. Instead of trying to maintain this
> > centrally in koji, do it at package level, using proven-packager
> privileges
> > to smooth the initial process.
> >
> > I.e. something like: OK, we don't want to build libreoffice for i686.
> > libreoffice is annotated with "ExcludeArch: %{ix86}", and *at the same
> time*
> > any packages which (transitively) BR:libreoffice, are also annotated.
> > (They don't even need to be rebuild.)
> > And then repeat for another "big" package.
> >
> > I think this way to go is OK because we mostly care about some of the
> > "big" packages that take a long time to build. Most low-level packages
> > build just fine on i686 so we don't care if they are built unnecessarily.
> >
> > And obviously the advantage is that this can be done now, and doesn't
> > require any new infra or maintenance. The only trick would be how to
> > figure out the transitive BR tree, but apparently there are some scripts
> > that people have.
>
> I really *don't* think a manual, individual opt-out like this is a good
> idea.
>
> Imagine the scenario where a package maintaner unilaterally adds
> "ExcludeArch: %{ix68}" to one of their packages. This might be an
> honest mistake, for example, because the repoquery was not done
> correctly, or because they thought that nothing depends on that
> package. Then, this results in cascading build failures of all
> dependent packages, because a broken build on any arch fails the whole
> build, requiring cascading changes to all packages in the dependency
> tree, more work for all manitainers that are involved.
>
> Because I think we should respect package maintainers' time, I don't
> think I should put the burden of figuring this out and fixing
> breakages on them, which is why I suggested a centralized approach
> that will not put more work on *every single package maintainer*.
>
> Fabio
> _______________________________________________
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
_______________________________________________
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
