On Fri, Mar 27, 2020 at 10:47 AM David Cantrell <dcantrell@xxxxxxxxxx> wrote: > > On Tue, Mar 24, 2020 at 10:32:26AM +0100, Aleksandra Fedorova wrote: > >As Ben is on PTO, I'd like to present the System-Wide Change > > > >https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose > [snip] > > It has taken me some time, but I have read through the entire thread in > addition to the change proposal. The idea sounds really interesting to me and > a lot of points have come up on the thread. I decided to group my responses > together as this single email after reading through the entire thread to make > it a bit easier to read (and to write). > > TL;DR -- I think this proposal should be broken up in to 2 proposals > > The turning point for me in the change proposal was the discussion of the RPM > spec file macros and getting in to the mechanics of how ELN will work. It > looks like a lot of other people had the same reaction because many of the > responses get in to the technical details and for some questions, there are no > answers yet. After thinking about it for a while, it would make sense to me > to have ELN come up in multiple phases/proposals. > > Suggested Proposals: > > 1) ELN buildroot and install media > > In this proposal, I'd like to see the ELN buildroot defined, the Koji > changes implemented, the automated builds implemented, and install media > composes happening. > > The expectation here should be that it is rough around the edges. But > doing this gives the community something to see, use, and discuss further > when reviewing the next change proposals. > > We should have some community goals with this proposal to capture a list of > EL vs. Fedora differences and how to address those per package and in the > context of ELN. > > 2) ELN lifecycle > > This gets in to more of the mechanics of how ELN builds can be handled by > the community. I do not think there is a one size fits all and we should > give developers control over how best to handle this for the packages they > maintain. > > The spec file macros, git branch ideas, inheritance, pull request workflow, > what builds block what composes, who is responsible for ELN failures, and > other expectations of package maintainers (both Fedora and RHEL) should be > discussed here. This proposal is definitely the policy side of things, but > I think it would be easier to talk about after #1 is done. > > Having seen multiple efforts to do a "RHEL rawhide" in a way (one even called > rhel-rawhide at one point), the ELN idea is one where the work is being > targeted in the right place. As a Fedora contributor, I see RHEL as a > customer and if we can make their work easier, I want to do that. As a RHEL > package maintainer, I see Fedora as a place where I can make my job easier as > a RHEL package maintainer. The more things we get right on the community side > of things, the easier it is to produce RHEL. > > Various comments from reading the thread: > > * I'm not crazy about the %{?rhel} macro name. I would prefer we use 'el' > instead to cover RHEL and CentOS and EPEL. Or at least have a 'el' macro > that covers all three of those. > The %{?rhel} macro name currently exists and is in use in some packages as I recall. > * I prefer the '.eln' dist tag carry a number indicating N+1 from the RHEL > major release. This should be ok in the community since Red Hat ultimately > makes the decision to version RHEL. This is an engineering decision and I > think it would help imply that ELN is _not_ meant for current RHEL. This > also lets us entertain the idea of multiple ELN major versions concurrently > should we ever want to do that. > I rather equate this to RHELhide, it should be evolving. Once N is branched (CentOS?) and moving on, this is N+1. This is the rolling development location. _______________________________________________ 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
