Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

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

 



On Fri, Jan 10, 2020 at 9:16 AM Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> wrote:
>
> On Thu, Jan 09, 2020 at 05:23:16PM -0500, Ben Cotton wrote:
> > On Thu, Jan 9, 2020 at 5:03 PM Zbigniew Jędrzejewski-Szmek
> > <zbyszek@xxxxxxxxx> wrote:
> > >
> > > 4. This certainly needs to be a "system wide change" with the related
> > >    additional info required for such changes. We certainly need releng
> > >    to sign off on this.
> > >
> > Apart from potential capacity impacts, this seems self-contained.
>
> Changes (in the sense of spec conditionals and such) to some
> yet-undefined subset of packages may necessary (for example if the
> architecture change has some effect on floating point computations,
> this could have a wide impact on packages doing numerical tests). So
> there is a potential for interaction with a large number of packagers.
>
> System-wide changes are also more widely announced (for example they
> are listed prominently in the release notes), which imo would be
> appropriate for something like a new architecture.

We are not proposing the new architecture. We are proposing a "staging
environment" for the current architecture. Which can be used for
experiments which currently can not be performed without disrupting
the release and user experience.

And the interaction with the maintainers you mention is not really
part of the Change, it is the continuous workflow, which is enabled by
it.

Note that we try to make it as light-weight as possible:

1) we reuse the infrastructure which is already available, like koji
builders. Because while hardware is costly, the human resources needed
to setup completely new infrastructure from scratch and then maintain
it in sync with the main infra cost way more;
2) we put all the new logic required to for this change (triggers,
feedback loop,..) outside of Fedora RelEng, so that we don't use
releng resources to maintain triggers and composes and the builds
themselves. This part will be maintained by change owners and people
interested in the development of the architecture update.

Thus, apart from raw compute resources, the impact of the change is quite small.

> Because of those two reasons, I'd argue that the category should be
> changed, but if you disagree, let's not discuss this further.

Based on the impact described above, I wouldn't consider the change system-wide.

But I think we touch an interesting topic here: It seems our
definition of Change is quite limited and focused on packaged changes.
And the work we propose doesn't really fit in this framework. I'm
going to start a separate thread on it.

> > I'll
> > grant that a reduced builder capacity would impact other contributors,
> > but that doesn't seem like the kind of case the system-wide change
> > definition is designed for.
> >
> > The change owner (bookwar) has already opened a ticket with RelEng[1]
> > and they will discuss what work is necessary for this at the next
> > meeting.
> >
> > [1] https://pagure.io/releng/issue/9154
>
> OK, thanks.
>

--
Aleksandra Fedorova
bookwar
_______________________________________________
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