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.
* 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.
* There has to be a deliverable for ELN. What I would prefer is a live or
install .iso. Something I can install on a spare system or in a virt
guest. If it is only available as a buildroot in Koji, that becomes "black
box" development which makes me less interested in working on it.
* There were a lot of comments about build differences between RHEL and Fedora
where certain features are disabled or build dependencies reduced (e.g.,
docs). I think this is something that the community could even discuss
rearchitecting at the package level in Fedora. Things like vim-minimal, for
instance. Having different packages built with different features
enabled/disabled. Some of these things may be easiest handled with macros
and others might be something we could handle by refactoring the packages
themselves.
* Regardless of the mechanics, there is going to be more work here. We all
need to understand the expectations of the work required of a package
maintainer and how best to coordinate with RHEL downstream. In many cases,
the package maintainers between RHEL and Fedora are the same. But in many
other cases they are not. As a community we should set some clear
guidelines on where the responsibility lies and have the right communication
workflow in place to make sure that's easy for everyone.
* On that same note, RHEL package maintainers should have an expectation to
co-maintain the corresponding package(s) in Fedora if they do not already.
Most of my comments here are on the mechanics, but before getting in to that
I'd like to see proposal #1 in some form happen first. I'd like to talk about
the actual details once I have download an ELN iso and installed in a virt
guest.
This is a huge effort and I appreciate the proposal and discussion so far.
I've wanted something like this in Fedora for a long time simply because it
makes RHEL easier to work on.
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
