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.
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
