On Fri, Mar 27, 2020 at 2:09 PM David Cantrell <dcantrell@xxxxxxxxxx> wrote: > > On Fri, Mar 27, 2020 at 01:48:15PM -0500, Justin Forbes wrote: > >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. > > Sorry, what I meant was I'm not crazy about the %{?rhel} macro for this work. > I would prefer a new macro for the ELN work to distinguish it from the > existing macros. > > >> * 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. > > I agree. The 'N' value seen in this dist tag should always be greater than > the latest major version we see for RHEL and CentOS. Sorry, I wasn't clear. I mean that the rhelhide/evolving nature of this seems it should carry no number, similar to the rawhide it is inheriting from. Let them deal with numbers in CentOS and RHEL. Justin _______________________________________________ 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
