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
