On Fri, Mar 27, 2020 at 8: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. > >> Numbering by RHEL versions can not be done based on RHEL release dates. Because RHEL stops consuming Fedora Rawhide code much earlier. To implement such numbering properly we would need to have a coordination with RHEL on a much deeper level. It will be additionally confusing, as RHEL can have as many overrides and branches on top of ELN packages as it wants and we can not say if ELN package built during the times of RHEL 9 development lands in RHEL 9 and is not consumed much later in RHEL 10 for example. ELN is not RHEL, it is what RHEL could have been if we try to cut it right now from Fedora Rawhide. Therefore there is no direct link between ELN state and RHEL versions. ELN is an abstract continuously developed "future" which will be consumed by downstream on downstream terms. If we ever go with versioning for ELN, then we could use Fedora versioning for it. This link is much cleaner and logical. But I don't really want to do that. I think that versioned tag for Fedora Rawhide is the reason why every time we do Fedora branching we have a major infrastructure hiccup. And the more infrastructure we add (ODCS, Gating..) the harder it is to coordinate the version jump in Rawhide across it. If Rawhide wasn't versioned, branching would be a small isolated effort, which could have been prepared and tested in advance without disrupting anyone's workflow. Rawhide would just keep going, with no changes. And new release branch would be _added_ to the infrastructure and opened to contributions as soon as infra for this particular new part is ready and verified. Now we have to do the verification of entire infra (because entire infra is impacted by branching). We have to do it after the change, as we can not test it on the side. And if something fails, it blocks everyone. Therefore if we _can_ proceed without versioning, I'd rather do it that way. > >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. > > Thanks, > > -- > David Cantrell <dcantrell@xxxxxxxxxx> > Red Hat, Inc. | Boston, MA | EST5EDT > _______________________________________________ > 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 -- 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
