On Fri, Mar 27, 2020 at 02:20:29PM -0500, Justin Forbes wrote:
On Fri, Mar 27, 2020 at 2:09 PM David Cantrell
<dcantrell(a)redhat.com> 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(a)redhat.com>
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.
I find it useful to have that information in the dist tag so that you can see
a built package and have an idea of when it was built.
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT