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