Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

There has been a lot of (really good!) discussion on the original
proposal thread, but as it has grown too large to follow anymore, I'm
restarting it. I have made numerous changes to the Change Proposal
page to improve the scope of the proposal as well as clarify some of
the questions that have come up repeatedly in the original thread.

Please see the newly-updated
https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
for more details[1].

== Summary ==
ELN is a new buildroot and compose process for Fedora that will take
Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux
compose. Feedback from this build, compose and integration testing
will be provided to Fedora packagers so that they can see the
potential impact of their changes on RHEL development.

== Owner ==

* Name: [[User:Bookwar| Aleksandra Fedorova]]
* Email: alpha(a)bookwar.info
* Name: [[User:Sgallagh | Stephen Gallagher]]
* Email: sgallagh(a)redhat.com



[1] List of changes between the original and new versions:
https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_C...
> -----BEGIN PGP SIGNATURE-----
>
> iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl5+FpgACgkQRduFpWgo
> bRE90QwAu8gIRcPcyct73D2jF+MBzmy7XFdlilLIcL4Z3RWINKgHcNUTw+jC9n3K
> jJdBMOUji1DAD+fw1UeuJ+x0ThMCg1zqYgRDalYE/7AiRWxjD73rQ5V3q7EKLycJ
> 6Al+n3rB+P5vy+TB9m/mB223hjmUxv5+FXEqmkNcpvZiRsTqIk5Ss+22zSoFhs8D
> 6DJE6yPTPiNiygJZBIgE508pXakHsl2CCpKNccHEpj5eNU0t93kbb7oWVJXf6i6Z
> Y09jvZLO4mVcn1vUIJRtpFJvNWbzIEIGyFuELgvHoVT66xSe4MwxvW0A6ChIwngQ
> mvNM43Ild6Lq29+qtVCje6fovh3yPzRWitoEwdClg4HOj5C2wymeQWO01a/ydQNg
> lUwmNnFHPZ4/2TtHWw64QkKdm9QP6bfmdMYJOy+iKhibmUiws4WheTB5L6zyh4ED
> pvLLszQvReqDj5N56Oghr5YquRdQLIACEfqm5s4A/iipwDEj3WY5niHzAt0jBz1q
> 6DnLPiZt
> =42JI
> -----END PGP SIGNATURE-----
>  
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
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/[e-mail]...

[Fabio Valentini]

On Fri, Mar 27, 2020 at 4:12 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA256
>
>  There has been a lot of (really good!) discussion on the original
>  proposal thread, but as it has grown too large to follow anymore, I'm
>  restarting it. I have made numerous changes to the Change Proposal
>  page to improve the scope of the proposal as well as clarify some of
>  the questions that have come up repeatedly in the original thread. 
I still think the only way to resolve conflicts (at least in some
cases) will be to have the option of a separate eln branch in
dist-git. Multiple people other than myself have voiced this opinion
in the original thread, but this option is still not mentioned in the
Change Proposal at all.

Maybe my suggestions were not clear enough, so let me try again.

Proposal: Use an (optional) eln branch in dist-git to resolve conflicts.

## Case 1: Improvements are applicable to both fedora and RHEL-next
In this case, there should be no conflict and no need for %if
spaghetti, changes can go into the master branch directly, without
conditionals.
The eln branch can either merge from master directly, or be a symbolic
link to it (TIL about symbolic refs in git).

## Case 2: Changes can easily be expressed with %if conditionals and
are clear to understand and easy to maintain
In this case, I think some maintainers might accept such changes in
rawhide. Same result as for Case 1.
If maintainers do not accept those changes, "goto Case 3".

## Case 3: Changes are big and/or not accepted for master by the
fedora maintainer
In this case, conditional-based solutions are probably ugly and need
special care.

I assume any regular rawhide change will break ELN builds, since the
conditionals will not be in effect for rawhide builds, and fedora
packages will probably not care.
Here, the eln branch can contain "downstream" changes, and it can be
rebased on top of master/rawhide automatically. If an automatic rebase
does not work, the ELN maintainer would have had to adapt the .spec
file manually anyway, so it does not matter to them if this happens in
the eln branch, or in the master branch (additionally, this kind of
maintenance should be easier, since neither the fedora, nor the ELN
maintainer has to deal with %if spaghetti!).

Additionally, since you're only going to build a reduced package set
for ELN, and I think you mentioned that you expect the number of
packages which will require "bigger" changes to be small, this should
scale very well. It would also give maintainers an "upgrade path" in
the case the eln and master branches are initially the same, but would
need to diverge later.

I hope this makes it clearer why I think using branches as a conflict
resolution tool - like for any other "release stream" - is more
general, and superior to "[we] will discuss alternative approaches on
an individual basis".

Please at least seriously consider this suggestion - up until now, you
only dismissed using branches with "this will not work / scale".

Fabio

> Please see the newly-updated
> https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
> for more details[1].
>
> == Summary ==
> ELN is a new buildroot and compose process for Fedora that will take
> Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux
> compose. Feedback from this build, compose and integration testing
> will be provided to Fedora packagers so that they can see the
> potential impact of their changes on RHEL development.
>
> == Owner ==
>
> * Name: [[User:Bookwar| Aleksandra Fedorova]]
> * Email: alpha(a)bookwar.info
> * Name: [[User:Sgallagh | Stephen Gallagher]]
> * Email: sgallagh(a)redhat.com
>
>
>
> [1] List of changes between the original and new versions:
>
https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_C...
> > -----BEGIN PGP SIGNATURE-----
> >
> > iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl5+FpgACgkQRduFpWgo
> > bRE90QwAu8gIRcPcyct73D2jF+MBzmy7XFdlilLIcL4Z3RWINKgHcNUTw+jC9n3K
> > jJdBMOUji1DAD+fw1UeuJ+x0ThMCg1zqYgRDalYE/7AiRWxjD73rQ5V3q7EKLycJ
> > 6Al+n3rB+P5vy+TB9m/mB223hjmUxv5+FXEqmkNcpvZiRsTqIk5Ss+22zSoFhs8D
> > 6DJE6yPTPiNiygJZBIgE508pXakHsl2CCpKNccHEpj5eNU0t93kbb7oWVJXf6i6Z
> > Y09jvZLO4mVcn1vUIJRtpFJvNWbzIEIGyFuELgvHoVT66xSe4MwxvW0A6ChIwngQ
> > mvNM43Ild6Lq29+qtVCje6fovh3yPzRWitoEwdClg4HOj5C2wymeQWO01a/ydQNg
> > lUwmNnFHPZ4/2TtHWw64QkKdm9QP6bfmdMYJOy+iKhibmUiws4WheTB5L6zyh4ED
> > pvLLszQvReqDj5N56Oghr5YquRdQLIACEfqm5s4A/iipwDEj3WY5niHzAt0jBz1q
> > 6DnLPiZt
> > =42JI
> > -----END PGP SIGNATURE----- 
>
_______________________________________________
> devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
> 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/[e-mail]...

[Robbie Harwood]

Stephen Gallagher <sgallagh(a)redhat.com&gt; writes:

>  Please see the newly-updated
>  https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
>  for more details[1]. 
This page states:

>  The fix will be done via a pull request that states a time limit. We
>  want the regular maintainers to see / comment / commit, but we also
>  don't want things to stall for months and get forgotten about. 
What happens at the end of the time limit?  Do you ProvenPackager the PR
in?

>  What if I do not want to have %if's in my spec files?
>
>  As long as your package builds in ELN then just maintain your package
>  like normal. If there is a build failure, the ELN SIG may provide a PR
>  as described above or will discuss alternative approaches on an
>  individual basis with you. 
So... if we don't want %ifs in our spec files, the ELN SIG will provide
us some?

>  Post build result to Fedora Messaging, so that it appears in Bodhi
> and
>  can be used as a gating test. 
So regular package updates are going to be gated on ELN.  This doesn't
sound like something non-RHEL maintainers will want.  What am I missing?

>  It is under discussion whether this snapshot will have its own
>  installation media. For now the preferred way to test ELN composes
>  would be to use standard Fedora Rawhide images and then include ELN as
>  an additional repository. 
Is there a dnf change that goes with this to prefer ELN content, then?

>  ELN artifacts will be made available for testing and development
>  purposes, but we will not be shipping any content produced from ELN
>  directly to the general public (such as on the standard mirror network
>  or via getfedora.org).
>
>  ...
>
>  Though it is a System-Wide Change it has no user-facing component. We
>  may announce it through other channels. 
I'm confused.  This is going to be installable and testable, but has no
user-facing component?  What's a user-facing component then?

Thanks,
--Robbie

[Pierre-Yves Chibon]

On Fri, Mar 27, 2020 at 12:02:40PM -0400, Robbie Harwood wrote:
>  Stephen Gallagher <sgallagh(a)redhat.com&gt; writes:
>  
>  > Please see the newly-updated
>  > https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
>  > for more details[1].
>  
>  This page states: 
[..]

>  > Post build result to Fedora Messaging, so that it appears in
> Bodhi and
>  > can be used as a gating test.
>  
>  So regular package updates are going to be gated on ELN.  This doesn't
>  sound like something non-RHEL maintainers will want.  What am I missing? 
"Can be used as a gating test" is different from "will be used for
gating".

What this line says is that the results from the tests will flow in with all the
other test results and as very every tests at the moment, the packager
maintainers can chose to gate on some tests or others, or chose not to gate
their packages at all.


Pierre

[Zbigniew Jędrzejewski-Szmek]

On Fri, Mar 27, 2020 at 11:07:41AM -0400, Stephen Gallagher wrote:
>  == Summary ==
>  ELN is a new buildroot and compose process for Fedora that will take
>  Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux
>  compose. Feedback from this build, compose and integration testing
>  will be provided to Fedora packagers so that they can see the
>  potential impact of their changes on RHEL development. 
Thanks, the new page is much better. Esp. this new summary is
massively better.

Some specific things which are still unclear:

>  Setup automation to trigger new ELN build every time there is a new
>  update submitted to Fedora Rawhide. 
Does "update" in this context mean the automatic bodhi update used for
gating? What does "submitted" mean — the time when the update is
requested, on when the update is pushed to rawhide, or ... ?

>  Post build result to Fedora Messaging, so that it appears in Bodhi
>  and can be used as a gating test 
Continuing with the previous question, is the "gating test" for the
original rawhide update?

>  The SIG will [...] maintain infrastructure required to build packages
> and composes; 
Does this mean that some new person will join releng?

>  we will not be shipping any content produced from ELN directly to
>  the general public (such as on the standard mirror network 
Hmm, so those packages will be pulled directly from koji? Is the
additional load acceptable?

>  Contingency mechanism: If this effort doesn’t land in Fedora 33 we
>  review it and decide whether it needs to be moved further to Fedora
>  34 or be cancelled. 
OK, and what about the case where it is enabled, and then during the
way it turns out to be too much hassle? Is there some sunset procedure
planned?

>  What if there is a feature RHEL wants in a package, how will that go
> in?
>  That is not in the scope of ELN. 
Does "not in scope" mean that the question is not answered, or does
it mean that ELN is not relevant to the question?

The latter seems a bit impossible. ELN is all about making rawhide
packages more like the packages in RHEL, and this naturally means
adding and removing features or changing dependencies or configuration
falls into the scope of ELN. I.e. if I'm a RHEL maintainer, opening
a PR against Fedora dist-git with a bunch of '%if %{eln}' conditionals
or not seems the most straightforward way to push towards having a
feature in RHEL...

Zbyszek

[Zbigniew Jędrzejewski-Szmek]

On Fri, Mar 27, 2020 at 12:02:40PM -0400, Robbie Harwood wrote:
>  Stephen Gallagher <sgallagh(a)redhat.com&gt; writes:
>  > It is under discussion whether this snapshot will have its own
>  > installation media. For now the preferred way to test ELN composes
>  > would be to use standard Fedora Rawhide images and then include ELN as
>  > an additional repository.
>  
>  Is there a dnf change that goes with this to prefer ELN content, then? 
Yeah, that's something I was trying to figure out too. As discussed
before, for rpm '.eln < .fc33', so if the same package is available
from both sources, the rawhide one will win.

>  > ELN artifacts will be made available for testing and
> development
>  > purposes, but we will not be shipping any content produced from ELN
>  > directly to the general public (such as on the standard mirror network
>  > or via getfedora.org).
>  > ...
>  >
>  > Though it is a System-Wide Change it has no user-facing component. We
>  > may announce it through other channels.
>  
>  I'm confused.  This is going to be installable and testable, but has no
>  user-facing component?  What's a user-facing component then? 
FWIW, I think it's OK to have to first install rawhide and then to
enable eln repos on top to have a working installation. Or to do
'dnf --installroot'. Building an an installer image and such doesn't
seem necessary, esp. in the beginning.

Zbyszek

[Neal Gompa]

On Fri, Mar 27, 2020 at 3:42 PM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
>  On Fri, Mar 27, 2020 at 12:02:40PM -0400, Robbie Harwood wrote:
>  > Stephen Gallagher <sgallagh(a)redhat.com&gt; writes:
>  > > It is under discussion whether this snapshot will have its own
>  > > installation media. For now the preferred way to test ELN composes
>  > > would be to use standard Fedora Rawhide images and then include ELN as
>  > > an additional repository.
>  >
>  > Is there a dnf change that goes with this to prefer ELN content, then?
>
>  Yeah, that's something I was trying to figure out too. As discussed
>  before, for rpm '.eln < .fc33', so if the same package is available
>  from both sources, the rawhide one will win.
>  
If there was a "dnf distro-sync --prefer-repo=foo" kind of feature,
maybe that'd work? Maybe repo priorities? I'm not sure how this would
work...

>  > > ELN artifacts will be made available for testing and
> development
>  > > purposes, but we will not be shipping any content produced from ELN
>  > > directly to the general public (such as on the standard mirror network
>  > > or via getfedora.org).
>  > > ...
>  > >
>  > > Though it is a System-Wide Change it has no user-facing component. We
>  > > may announce it through other channels.
>  >
>  > I'm confused.  This is going to be installable and testable, but has no
>  > user-facing component?  What's a user-facing component then?
>
>  FWIW, I think it's OK to have to first install rawhide and then to
>  enable eln repos on top to have a working installation. Or to do
>  'dnf --installroot'. Building an an installer image and such doesn't
>  seem necessary, esp. in the beginning.
>  
I would argue that it is necessary, if it's intended to be as
interesting and useful as this Change proposes.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Justin Forbes]

On Fri, Mar 27, 2020 at 2:42 PM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
>  On Fri, Mar 27, 2020 at 12:02:40PM -0400, Robbie Harwood wrote:
>  > Stephen Gallagher <sgallagh(a)redhat.com&gt; writes:
>  > > It is under discussion whether this snapshot will have its own
>  > > installation media. For now the preferred way to test ELN composes
>  > > would be to use standard Fedora Rawhide images and then include ELN as
>  > > an additional repository.
>  >
>  > Is there a dnf change that goes with this to prefer ELN content, then?
>
>  Yeah, that's something I was trying to figure out too. As discussed
>  before, for rpm '.eln < .fc33', so if the same package is available
>  from both sources, the rawhide one will win.
>  
Can this be handled with the existing 'priority' directive in
repository config files?

[Kevin Fenzi]

So, in general I think this is a pretty cool idea and I am in favor of
it. I do think we are going to have to learn and adjust as we go here
somewhat, we can't be 100% sure of how this will pan out. Of course we
should plan as best we can now too. :) 

Some random things in no particular order: 

* This is the sort of thing that doesn't really fit the change process
too well, since it's not really tied to a release or adding some
deliverable to a release or whatever. I guess it's the best we have
though currently. 

* So, while you say "we will not be shipping any content produced from
ELN directly to the general public", it sounds like ODCS composes and of
course packages from koji will be available for those that know where to
look for them, which brings up: 

** Can you add that you will document how these packages interact
somewhere? I guess the ELN wiki page if nothing else. ie, say eln
packages are built with different compiler flags, we should have some
way to tell people who get a hold of them what hardware will work on
them or fail completely. 

** If we get a lot of demand we may need to redo stuff around ODCS, as
it's currently just a pair of vm's with a nfs mount to serve those
composes. If there's a lot of load we may need to put some caching in
front of it or put it on a dedicated download server or something. 

* Might note that this will require a new "release" in bodhi. I don't
think thats much work (might just be config), but could be good to
check.

* Might add in the benifit to fedora that ODCS will get worked on and
perhaps someday we can move all our other composes into it. (This would
allow us to not have a bodhi-backend machine, it could be all in
openshift, and let us let koji do the heavy lifting instead of a
rawhide-composer instance)

* Suggestion: How about making a ELN tracker bug and require anything
that uses %eln or has some failure to build being filed against the
package and tracked in the tracker. This would allow people who care to
follow along and see how many issues there are, etc. 

* Depending on when we get this going, timing might be not that great.
We have the datacenter move coming up. In late may/early june we will
likely have a lot less capacity of builders until we can re-add machines
as they arrive from shipping. I think as long as you don't mind things
being slow, we could tune it so ELN builds are not as high priority as
normal builds (so they will wait until there's capacity for them). They
would still finish, just might take longer and not impact other builds. 
In fact, perhaps we should set this from the start and see if it causes
you any issues? 

* Additionally there will likely be some more disk usage from this (on
ODCS and in koji). However, if we only need to keep around the last
working eln build and don't keep a bunch of composes I don't think this
should be too big an issue. Definitely something to watch tho. 

Anyhow, those are probibly also a lot of things we can just sort out
with releng, but figured I'd throw them out there while I was thinking
about them. 

Overall I think this could be a very nice effort and won't even
hopefully cost us much in time and energy. 

kevin

[Kevin Fenzi]

On Fri, Mar 27, 2020 at 03:19:01PM -0500, Justin Forbes wrote:
>  On Fri, Mar 27, 2020 at 2:42 PM Zbigniew Jędrzejewski-Szmek
>  <zbyszek(a)in.waw.pl&gt; wrote:
>  >
>  > On Fri, Mar 27, 2020 at 12:02:40PM -0400, Robbie Harwood wrote:
>  > > Stephen Gallagher <sgallagh(a)redhat.com&gt; writes:
>  > > > It is under discussion whether this snapshot will have its own
>  > > > installation media. For now the preferred way to test ELN composes
>  > > > would be to use standard Fedora Rawhide images and then include ELN as
>  > > > an additional repository.
>  > >
>  > > Is there a dnf change that goes with this to prefer ELN content, then?
>  >
>  > Yeah, that's something I was trying to figure out too. As discussed
>  > before, for rpm '.eln < .fc33', so if the same package is available
>  > from both sources, the rawhide one will win.
>  >
>  
>  Can this be handled with the existing 'priority' directive in
>  repository config files? 
I think this is a nice behavior and we should consider not messing with
it any. (ie, rawhide is always newer). 

Since we are not advertising this / marketing / expecting that normal
users would use it, why not make it easy for them to go back if they
install some eln packages?

If you are one of the developers/testers you can use distro-sync, or a
composed eln media to test and then just 'dnf update' (or distro-sync)
back to rawhide. 

This also means if someone installs a .eln package on a stable fedora,
it will be 'upgraded' away to next time the package updates. Or if they
go from say f31 to f32. 

kevin

[Zbigniew Jędrzejewski-Szmek]

On Fri, Mar 27, 2020 at 04:45:50PM -0700, Kevin Fenzi wrote:
>  On Fri, Mar 27, 2020 at 03:19:01PM -0500, Justin Forbes wrote:
>  > On Fri, Mar 27, 2020 at 2:42 PM Zbigniew Jędrzejewski-Szmek
>  > <zbyszek(a)in.waw.pl&gt; wrote:
>  > >
>  > > On Fri, Mar 27, 2020 at 12:02:40PM -0400, Robbie Harwood wrote:
>  > > > Stephen Gallagher <sgallagh(a)redhat.com&gt; writes:
>  > > > > It is under discussion whether this snapshot will have its own
>  > > > > installation media. For now the preferred way to test ELN composes
>  > > > > would be to use standard Fedora Rawhide images and then include ELN
> as
>  > > > > an additional repository.
>  > > >
>  > > > Is there a dnf change that goes with this to prefer ELN content, then?
>  > >
>  > > Yeah, that's something I was trying to figure out too. As discussed
>  > > before, for rpm '.eln < .fc33', so if the same package is available
>  > > from both sources, the rawhide one will win.
>  > >
>  > 
>  > Can this be handled with the existing 'priority' directive in
>  > repository config files?
>  
>  I think this is a nice behavior and we should consider not messing with
>  it any. (ie, rawhide is always newer).  
I think the question about priority was asked because:
When installing eln by "upgrading" from rawhide, you hardly want to go
package by package, but instead want to do a single command to install
everything that can be installed. That's the first time where you want
eln packages to have priority.

But then rawhide moves on, and some eln packages fail to build. Then
you still want to keep the eln stuff (and not revert to to the rawhide
versions of everything), but install the rawhide versions if that is
the only way to satisfy dependencies.

So this question is how to set up inheritance and priorities to get a
workable system like that. (Or maybe it's supposed to work in a
different way?)

Zbyszek

[Miro Hrončok]

On 27. 03. 20 17:02, Robbie Harwood wrote:
> > What if I do not want to have %if's in my spec files?
> >
> > As long as your package builds in ELN then just maintain your package
> > like normal. If there is a build failure, the ELN SIG may provide a PR
> > as described above or will discuss alternative approaches on an
> > individual basis with you.
>  So... if we don't want %ifs in our spec files, the ELN SIG will provide
>  us some? 
This is my understanding as well.

Thanks Stephen for reworking the proposal. However it still looks like you heard 
the feedback but the response is "we are doing it our way anyway".

Please, consider the feedback that many people provided here, do not outright 
reject it.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Kevin Fenzi]

On Sat, Mar 28, 2020 at 07:10:55AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
>  
>  I think the question about priority was asked because:
>  When installing eln by "upgrading" from rawhide, you hardly want to go
>  package by package, but instead want to do a single command to install
>  everything that can be installed. That's the first time where you want
>  eln packages to have priority. 
ok. It's unclear to me if there is supposed to be such a path. 
I know people in these threads have suggested it, but I don't know that
the change owners want it. 

>  But then rawhide moves on, and some eln packages fail to build. Then
>  you still want to keep the eln stuff (and not revert to to the rawhide
>  versions of everything), but install the rawhide versions if that is
>  the only way to satisfy dependencies. 
Sure, if the intent is for people to have long lived installs, but thats
not what I got at all. 

>  So this question is how to set up inheritance and priorities to get
> a
>  workable system like that. (Or maybe it's supposed to work in a
>  different way?) 
My understanding so far is that if you want to test it, you do a install
from it's media, test and then destroy it until next time. 
Or if you want to test just a single or small group of packages you pull
them and load them into your rawhide install, test, and then a update
removes them so you are back at rawhide state for the next one. 

But I could be misunderstanding, or perhaps change owners do want to
allow for longer lived installs, in which case you are right that they
would want some way to make the eln packages 'newer' than rawhide
instead of older. 

Perhaps it's time for us to add some ugly hacks to rpm and make:

f > fc
eln > f

:)

kevin

[clime]

From the proposal:

 %if 0%{?fedora} < 32 && 0%{?rhel} <= 8

The fix will be done via a pull request that states a time limit. We
want the regular maintainers to see / comment / commit, but we also
don't want things to stall for months and get forgotten about.

---

What kind of pull request is that? It's like saying either merge or ...
In other words, great way to lose community members.

On Sat, 28 Mar 2020 at 21:07, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>
> On Sat, Mar 28, 2020 at 07:10:55AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> >
> > I think the question about priority was asked because:
> > When installing eln by "upgrading" from rawhide, you hardly want to
go
> > package by package, but instead want to do a single command to install
> > everything that can be installed. That's the first time where you want
> > eln packages to have priority.
>
> ok. It's unclear to me if there is supposed to be such a path.
> I know people in these threads have suggested it, but I don't know that
> the change owners want it.
>
> > But then rawhide moves on, and some eln packages fail to build. Then
> > you still want to keep the eln stuff (and not revert to to the rawhide
> > versions of everything), but install the rawhide versions if that is
> > the only way to satisfy dependencies.
>
> Sure, if the intent is for people to have long lived installs, but thats
> not what I got at all.
>
> > So this question is how to set up inheritance and priorities to get a
> > workable system like that. (Or maybe it's supposed to work in a
> > different way?)
>
> My understanding so far is that if you want to test it, you do a install
> from it's media, test and then destroy it until next time.
> Or if you want to test just a single or small group of packages you pull
> them and load them into your rawhide install, test, and then a update
> removes them so you are back at rawhide state for the next one.
>
> But I could be misunderstanding, or perhaps change owners do want to
> allow for longer lived installs, in which case you are right that they
> would want some way to make the eln packages 'newer' than rawhide
> instead of older.
>
> Perhaps it's time for us to add some ugly hacks to rpm and make:
>
> f > fc
> eln > f
>
> :)
>
> kevin
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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/[e-mail]

[Zbigniew Jędrzejewski-Szmek]

On Sat, Mar 28, 2020 at 01:06:55PM -0700, Kevin Fenzi wrote:
>  On Sat, Mar 28, 2020 at 07:10:55AM +0000, Zbigniew Jędrzejewski-Szmek
> wrote:
>  > 
>  > I think the question about priority was asked because:
>  > When installing eln by "upgrading" from rawhide, you hardly want to go
>  > package by package, but instead want to do a single command to install
>  > everything that can be installed. That's the first time where you want
>  > eln packages to have priority.
>  
>  ok. It's unclear to me if there is supposed to be such a path. 
>  I know people in these threads have suggested it, but I don't know that
>  the change owners want it. 
>  
>  > But then rawhide moves on, and some eln packages fail to build. Then
>  > you still want to keep the eln stuff (and not revert to to the rawhide
>  > versions of everything), but install the rawhide versions if that is
>  > the only way to satisfy dependencies.
>  
>  Sure, if the intent is for people to have long lived installs, but thats
>  not what I got at all. 
>  
>  > So this question is how to set up inheritance and priorities to get a
>  > workable system like that. (Or maybe it's supposed to work in a
>  > different way?)
>  
>  My understanding so far is that if you want to test it, you do a install
>  from it's media, test and then destroy it until next time.  
Hm, I'm pretty certain that there were not installation media planned. In
fact, there were supposed to be no deliverables...

>  Or if you want to test just a single or small group of packages you
> pull
>  them and load them into your rawhide install, test, and then a update
>  removes them so you are back at rawhide state for the next one. 
>  
>  But I could be misunderstanding, or perhaps change owners do want to
>  allow for longer lived installs, in which case you are right that they
>  would want some way to make the eln packages 'newer' than rawhide
>  instead of older. 
>  
>  Perhaps it's time for us to add some ugly hacks to rpm and make:
>  
>  f > fc
>  eln > f 
To do just that, we wouldn't need a hack. g > f, and + > anything.
But without knowing what the intended way to consume this is, discussing
technical details is just idle speculation.

Zbyszek

[clime]

You can make a separate namespace for this in dist-git. It doesn't need to
be a separate branch. That way, you won't be disturbing anyone elses space.

clime

On Friday, 27 March 2020, Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:

>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA256
>
>  There has been a lot of (really good!) discussion on the original
>  proposal thread, but as it has grown too large to follow anymore, I'm
>  restarting it. I have made numerous changes to the Change Proposal
>  page to improve the scope of the proposal as well as clarify some of
>  the questions that have come up repeatedly in the original thread.
>
>  Please see the newly-updated
>  https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
>  for more details[1].
>
>  == Summary ==
>  ELN is a new buildroot and compose process for Fedora that will take
>  Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux
>  compose. Feedback from this build, compose and integration testing
>  will be provided to Fedora packagers so that they can see the
>  potential impact of their changes on RHEL development.
>
>  == Owner ==
>
>  * Name: [[User:Bookwar| Aleksandra Fedorova]]
>  * Email: alpha(a)bookwar.info
>  * Name: [[User:Sgallagh | Stephen Gallagher]]
>  * Email: sgallagh(a)redhat.com
>
>
>
>  [1] List of changes between the original and new versions:
>  https://fedoraproject.org/w/index.php?title=Changes%2FELN_
>  Buildroot_and_Compose&type=revision&diff=569655&oldid=569549
> >  -----BEGIN PGP SIGNATURE-----
> >
> >  iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl5+FpgACgkQRduFpWgo
> >  bRE90QwAu8gIRcPcyct73D2jF+MBzmy7XFdlilLIcL4Z3RWINKgHcNUTw+jC9n3K
> >  jJdBMOUji1DAD+fw1UeuJ+x0ThMCg1zqYgRDalYE/7AiRWxjD73rQ5V3q7EKLycJ
> >  6Al+n3rB+P5vy+TB9m/mB223hjmUxv5+FXEqmkNcpvZiRsTqIk5Ss+22zSoFhs8D
> >  6DJE6yPTPiNiygJZBIgE508pXakHsl2CCpKNccHEpj5eNU0t93kbb7oWVJXf6i6Z
> >  Y09jvZLO4mVcn1vUIJRtpFJvNWbzIEIGyFuELgvHoVT66xSe4MwxvW0A6ChIwngQ
> >  mvNM43Ild6Lq29+qtVCje6fovh3yPzRWitoEwdClg4HOj5C2wymeQWO01a/ydQNg
> >  lUwmNnFHPZ4/2TtHWw64QkKdm9QP6bfmdMYJOy+iKhibmUiws4WheTB5L6zyh4ED
> >  pvLLszQvReqDj5N56Oghr5YquRdQLIACEfqm5s4A/iipwDEj3WY5niHzAt0jBz1q
> >  6DnLPiZt
> >  =42JI
> >  -----END PGP SIGNATURE----- 
>  _______________________________________________
>  devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-announce-leave@lists.
>  fedoraproject.org
>  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-
>  announce(a)lists.fedoraproject.org
>

[clime]

On Sunday, 29 March 2020, clime <clime(a)fedoraproject.org&gt; wrote:

>  You can make a separate namespace for this in dist-git. It
> doesn't need to
>  be a separate branch. That way, you won't be disturbing anyone elses space. 

or simply forks...


>  clime
>
>  On Friday, 27 March 2020, Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > There has been a lot of (really good!) discussion on the original
> > proposal thread, but as it has grown too large to follow anymore, I'm
> > restarting it. I have made numerous changes to the Change Proposal
> > page to improve the scope of the proposal as well as clarify some of
> > the questions that have come up repeatedly in the original thread.
> >
> > Please see the newly-updated
> > https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
> > for more details[1].
> >
> > == Summary ==
> > ELN is a new buildroot and compose process for Fedora that will take
> > Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux
> > compose. Feedback from this build, compose and integration testing
> > will be provided to Fedora packagers so that they can see the
> > potential impact of their changes on RHEL development.
> >
> > == Owner ==
> >
> > * Name: [[User:Bookwar| Aleksandra Fedorova]]
> > * Email: alpha(a)bookwar.info
> > * Name: [[User:Sgallagh | Stephen Gallagher]]
> > * Email: sgallagh(a)redhat.com
> >
> >
> >
> > [1] List of changes between the original and new versions:
> > https://fedoraproject.org/w/index.php?title=Changes%2FELN_Bu
> > ildroot_and_Compose&type=revision&diff=569655&oldid=569549
> > > -----BEGIN PGP SIGNATURE-----
> > >
> > > iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl5+FpgACgkQRduFpWgo
> > > bRE90QwAu8gIRcPcyct73D2jF+MBzmy7XFdlilLIcL4Z3RWINKgHcNUTw+jC9n3K
> > > jJdBMOUji1DAD+fw1UeuJ+x0ThMCg1zqYgRDalYE/7AiRWxjD73rQ5V3q7EKLycJ
> > > 6Al+n3rB+P5vy+TB9m/mB223hjmUxv5+FXEqmkNcpvZiRsTqIk5Ss+22zSoFhs8D
> > > 6DJE6yPTPiNiygJZBIgE508pXakHsl2CCpKNccHEpj5eNU0t93kbb7oWVJXf6i6Z
> > > Y09jvZLO4mVcn1vUIJRtpFJvNWbzIEIGyFuELgvHoVT66xSe4MwxvW0A6ChIwngQ
> > > mvNM43Ild6Lq29+qtVCje6fovh3yPzRWitoEwdClg4HOj5C2wymeQWO01a/ydQNg
> > > lUwmNnFHPZ4/2TtHWw64QkKdm9QP6bfmdMYJOy+iKhibmUiws4WheTB5L6zyh4ED
> > > pvLLszQvReqDj5N56Oghr5YquRdQLIACEfqm5s4A/iipwDEj3WY5niHzAt0jBz1q
> > > 6DnLPiZt
> > > =42JI
> > > -----END PGP SIGNATURE----- 
> >
> _______________________________________________
> > devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-announce-leave(a)lists.fed
> > oraproject.org
> > 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.or
> > g/archives/list/devel-announce(a)lists.fedoraproject.org
> >
>

[Aleksandra Fedorova]

Hi, Fabio,

On Fri, Mar 27, 2020 at 4:42 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  On Fri, Mar 27, 2020 at 4:12 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  >
>  > -----BEGIN PGP SIGNED MESSAGE-----
>  > Hash: SHA256
>  >
>  > There has been a lot of (really good!) discussion on the original
>  > proposal thread, but as it has grown too large to follow anymore, I'm
>  > restarting it. I have made numerous changes to the Change Proposal
>  > page to improve the scope of the proposal as well as clarify some of
>  > the questions that have come up repeatedly in the original thread.
>
>  I still think the only way to resolve conflicts (at least in some
>  cases) will be to have the option of a separate eln branch in
>  dist-git. Multiple people other than myself have voiced this opinion
>  in the original thread, but this option is still not mentioned in the
>  Change Proposal at all.
>
>  Maybe my suggestions were not clear enough, so let me try again.
>
>  Proposal: Use an (optional) eln branch in dist-git to resolve conflicts.
>
>  ## Case 1: Improvements are applicable to both fedora and RHEL-next
>  In this case, there should be no conflict and no need for %if
>  spaghetti, changes can go into the master branch directly, without
>  conditionals.
>  The eln branch can either merge from master directly, or be a symbolic
>  link to it (TIL about symbolic refs in git).
>
>  ## Case 2: Changes can easily be expressed with %if conditionals and
>  are clear to understand and easy to maintain
>  In this case, I think some maintainers might accept such changes in
>  rawhide. Same result as for Case 1.
>  If maintainers do not accept those changes, "goto Case 3".
>
>  ## Case 3: Changes are big and/or not accepted for master by the
>  fedora maintainer
>  In this case, conditional-based solutions are probably ugly and need
>  special care.
>
>  I assume any regular rawhide change will break ELN builds, since the
>  conditionals will not be in effect for rawhide builds, and fedora
>  packages will probably not care.
>  Here, the eln branch can contain "downstream" changes, and it can be
>  rebased on top of master/rawhide automatically. If an automatic rebase
>  does not work, the ELN maintainer would have had to adapt the .spec
>  file manually anyway, so it does not matter to them if this happens in
>  the eln branch, or in the master branch (additionally, this kind of
>  maintenance should be easier, since neither the fedora, nor the ELN
>  maintainer has to deal with %if spaghetti!).
>
>  Additionally, since you're only going to build a reduced package set
>  for ELN, and I think you mentioned that you expect the number of
>  packages which will require "bigger" changes to be small, this should
>  scale very well. It would also give maintainers an "upgrade path" in
>  the case the eln and master branches are initially the same, but would
>  need to diverge later.
>
>  I hope this makes it clearer why I think using branches as a conflict
>  resolution tool - like for any other "release stream" - is more
>  general, and superior to "[we] will discuss alternative approaches on
>  an individual basis".
>
>  Please at least seriously consider this suggestion - up until now, you
>  only dismissed using branches with "this will not work / scale". 
We are not ignoring the branching suggestion. We have thought about
it, and we have argued about it.

And the main reason why we don't want to implement branching is not
the cost and scalability of it, but the fact that It solves a
different problem.

The three cases you mentioned describe the solution how we can create
a downstream package from upstream.
It is a working mechanism, we know that. I have personally implemented
a similar thing for Mirantis OpenStack distribution not that long ago.
For this task branching makes sense, as well as versioning with RHEL
version numbers.

But we are not proposing to start building downstream packages by
downstream maintainers on Fedora infrastructure.

We want to build a new development tool for _Fedora_. Its purpose is
to work on Fedora. Its goals are to track and reduce dependency trees
in Fedora to help with Fedora Minimization objective, and to find
issues in Fedora packaging which makes it harder to use by downstream,
and to bring downstream maintainers to Fedora, so that they can help
in _Fedora_ development.

ELN is a Fedora feature. It helps downstream, it makes Fedora more
valuable for downstream, but it is still a Fedora feature. Thus when
in case #3 we have a fallback from Fedora to downstream, it falls back
not from Fedora Rawhide to ELN, but it falls from Fedora Rawhide and
ELN compilation of it all the way back to the downstream.

So yes, in case #3, when downstream can not find a compromise with
Fedora packagers, even via ELN option, then downstream does the
branching. But this branching is not in the scope of the proposed ELN
change.

>  Fabio
>
>  > Please see the newly-updated
>  > https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
>  > for more details[1].
>  >
>  > == Summary ==
>  > ELN is a new buildroot and compose process for Fedora that will take
>  > Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux
>  > compose. Feedback from this build, compose and integration testing
>  > will be provided to Fedora packagers so that they can see the
>  > potential impact of their changes on RHEL development.
>  >
>  > == Owner ==
>  >
>  > * Name: [[User:Bookwar| Aleksandra Fedorova]]
>  > * Email: alpha(a)bookwar.info
>  > * Name: [[User:Sgallagh | Stephen Gallagher]]
>  > * Email: sgallagh(a)redhat.com
>  >
>  >
>  >
>  > [1] List of changes between the original and new versions:
>  >
> https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_C...
> >  > -----BEGIN PGP SIGNATURE-----
> >  >
> >  > iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl5+FpgACgkQRduFpWgo
> >  > bRE90QwAu8gIRcPcyct73D2jF+MBzmy7XFdlilLIcL4Z3RWINKgHcNUTw+jC9n3K
> >  > jJdBMOUji1DAD+fw1UeuJ+x0ThMCg1zqYgRDalYE/7AiRWxjD73rQ5V3q7EKLycJ
> >  > 6Al+n3rB+P5vy+TB9m/mB223hjmUxv5+FXEqmkNcpvZiRsTqIk5Ss+22zSoFhs8D
> >  > 6DJE6yPTPiNiygJZBIgE508pXakHsl2CCpKNccHEpj5eNU0t93kbb7oWVJXf6i6Z
> >  > Y09jvZLO4mVcn1vUIJRtpFJvNWbzIEIGyFuELgvHoVT66xSe4MwxvW0A6ChIwngQ
> >  > mvNM43Ild6Lq29+qtVCje6fovh3yPzRWitoEwdClg4HOj5C2wymeQWO01a/ydQNg
> >  > lUwmNnFHPZ4/2TtHWw64QkKdm9QP6bfmdMYJOy+iKhibmUiws4WheTB5L6zyh4ED
> >  > pvLLszQvReqDj5N56Oghr5YquRdQLIACEfqm5s4A/iipwDEj3WY5niHzAt0jBz1q
> >  > 6DnLPiZt
> >  > =42JI
> >  > -----END PGP SIGNATURE----- 
>  >
> _______________________________________________
>  > devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
>  > 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/[e-mail]...
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail] 


-- 
-- 
Aleksandra Fedorova
bookwar

[Aleksandra Fedorova]

Hi,

On Sat, Mar 28, 2020 at 11:25 PM clime <clime(a)fedoraproject.org&gt; wrote:
>  From the proposal:
>
>   %if 0%{?fedora} < 32 && 0%{?rhel} <= 8
>
>  The fix will be done via a pull request that states a time limit. We
>  want the regular maintainers to see / comment / commit, but we also
>  don't want things to stall for months and get forgotten about.
>
>  ---
>
>  What kind of pull request is that? It's like saying either merge or ...
>  In other words, great way to lose community members. 
This is a better version of what proven packages already do nowadays.

If package already has a disttag-specific conditional, and this
conditional leads to a build failure in the eln-environment, then we
need a fix for that. Here we are not talking about introducing new
conditionals, feature switches or dependency adjustments. We will be
fixing the existing conditional so that package can be built.

Currently proven packagers fix such build failures directly. We will
propose changes via pull requests, so that maintainer has a
possibility to say "no", or to say "do it differently". But if we can
not get any feedback from a maintainer on it, we will fix the build
failure.

-- 
Aleksandra Fedorova
bookwar

[clime]

On Sun, 29 Mar 2020 at 13:34, Aleksandra Fedorova <alpha(a)bookwar.info&gt; wrote:
>  Hi,
>
>  On Sat, Mar 28, 2020 at 11:25 PM clime <clime(a)fedoraproject.org&gt; wrote:
>  >
>  > From the proposal:
>  >
>  >  %if 0%{?fedora} < 32 && 0%{?rhel} <= 8
>  >
>  > The fix will be done via a pull request that states a time limit. We
>  > want the regular maintainers to see / comment / commit, but we also
>  > don't want things to stall for months and get forgotten about.
>  >
>  > ---
>  >
>  > What kind of pull request is that? It's like saying either merge or ...
>  > In other words, great way to lose community members.
>
>  This is a better version of what proven packages already do nowadays.
>
>  If package already has a disttag-specific conditional, and this
>  conditional leads to a build failure in the eln-environment, then we
>  need a fix for that. Here we are not talking about introducing new
>  conditionals, feature switches or dependency adjustments. We will be
>  fixing the existing conditional so that package can be built.
>
>  Currently proven packagers fix such build failures directly. We will
>  propose changes via pull requests, so that maintainer has a
>  possibility to say "no", or to say "do it differently". But if we
> can
>  not get any feedback from a maintainer on it, we will fix the build
>  failure. 
Hi,

I think it would be nice to say in the change that it's okay to say
"no" and what
ELN SIG will do in that case.

clime

>
> --
> Aleksandra Fedorova
> bookwar
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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/[e-mail]

[Aleksandra Fedorova]

On Sun, Mar 29, 2020 at 2:36 PM clime <clime(a)fedoraproject.org&gt; wrote:
>  On Sun, 29 Mar 2020 at 13:34, Aleksandra Fedorova <alpha(a)bookwar.info&gt; wrote:
>  >
>  > Hi,
>  >
>  > On Sat, Mar 28, 2020 at 11:25 PM clime <clime(a)fedoraproject.org&gt; wrote:
>  > >
>  > > From the proposal:
>  > >
>  > >  %if 0%{?fedora} < 32 && 0%{?rhel} <= 8
>  > >
>  > > The fix will be done via a pull request that states a time limit. We
>  > > want the regular maintainers to see / comment / commit, but we also
>  > > don't want things to stall for months and get forgotten about.
>  > >
>  > > ---
>  > >
>  > > What kind of pull request is that? It's like saying either merge or ...
>  > > In other words, great way to lose community members.
>  >
>  > This is a better version of what proven packages already do nowadays.
>  >
>  > If package already has a disttag-specific conditional, and this
>  > conditional leads to a build failure in the eln-environment, then we
>  > need a fix for that. Here we are not talking about introducing new
>  > conditionals, feature switches or dependency adjustments. We will be
>  > fixing the existing conditional so that package can be built.
>  >
>  > Currently proven packagers fix such build failures directly. We will
>  > propose changes via pull requests, so that maintainer has a
>  > possibility to say "no", or to say "do it differently". But if
> we can
>  > not get any feedback from a maintainer on it, we will fix the build
>  > failure.
>
>  Hi,
>
>  I think it would be nice to say in the change that it's okay to say
>  "no" 
It is a common sense. I don't see how it can be interpreted the other way.

>  and what
>  ELN SIG will do in that case. 
It is described as other options in the change: We talk, we look into
options, we may consider removing the conditional altogether, if it is
not relevant anymore and continue using a clean "unconditionalized"
package.

If you are asking me what I am going to do if I meet Fedora packager,
who deliberately _adds_ conditional to the package to make this
package to fail to build in the eln environment and refuses to remove
it, then the answer is - I don't know. But I will be surprised, and I
will start questioning my life choices, for sure.

>  clime
>
>  >
>  > --
>  > Aleksandra Fedorova
>  > bookwar
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  > 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/[e-mail]
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail] 
-- 
Aleksandra Fedorova
bookwar

[clime]

On Sun, 29 Mar 2020 at 15:20, Aleksandra Fedorova <alpha(a)bookwar.info&gt; wrote:
>  On Sun, Mar 29, 2020 at 2:36 PM clime <clime(a)fedoraproject.org&gt; wrote:
>  >
>  > On Sun, 29 Mar 2020 at 13:34, Aleksandra Fedorova <alpha(a)bookwar.info&gt; wrote:
>  > >
>  > > Hi,
>  > >
>  > > On Sat, Mar 28, 2020 at 11:25 PM clime <clime(a)fedoraproject.org&gt; wrote:
>  > > >
>  > > > From the proposal:
>  > > >
>  > > >  %if 0%{?fedora} < 32 && 0%{?rhel} <= 8
>  > > >
>  > > > The fix will be done via a pull request that states a time limit. We
>  > > > want the regular maintainers to see / comment / commit, but we also
>  > > > don't want things to stall for months and get forgotten about.
>  > > >
>  > > > ---
>  > > >
>  > > > What kind of pull request is that? It's like saying either merge or
> ...
>  > > > In other words, great way to lose community members.
>  > >
>  > > This is a better version of what proven packages already do nowadays.
>  > >
>  > > If package already has a disttag-specific conditional, and this
>  > > conditional leads to a build failure in the eln-environment, then we
>  > > need a fix for that. Here we are not talking about introducing new
>  > > conditionals, feature switches or dependency adjustments. We will be
>  > > fixing the existing conditional so that package can be built.
>  > >
>  > > Currently proven packagers fix such build failures directly. We will
>  > > propose changes via pull requests, so that maintainer has a
>  > > possibility to say "no", or to say "do it differently". But
> if we can
>  > > not get any feedback from a maintainer on it, we will fix the build
>  > > failure.
>  >
>  > Hi,
>  >
>  > I think it would be nice to say in the change that it's okay to say
>  > "no"
>
>  It is a common sense. I don't see how it can be interpreted the other way. 
Well, the change doesn't describe concretely what to do in such a case
except "we will talk about it or look into the options".

If you said something like:

"ELN SIG may opt for maintaining an ELN version of a package in a fork
in case upstream maintainer doesn't wish to support the eln use-case."
+ technical details of this should be figured out (in terms of
auto-syncing).

It would indicate that you are ready for the situation, i.e. you are
ready to respect a maintainers' wish.

Idk, maybe you also consider this common sense or you haven't thought
about it or something else.

But I think that being more explicit in the change description could
only help for people to understand better what it means for them.

>
> > and what
> > ELN SIG will do in that case.
>
> It is described as other options in the change: We talk, we look into
> options, we may consider removing the conditional altogether, if it is
> not relevant anymore and continue using a clean "unconditionalized"
> package.
>
> If you are asking me what I am going to do if I meet Fedora packager,
> who deliberately _adds_ conditional to the package to make this
> package to fail to build in the eln environment and refuses to remove
> it, then the answer is - I don't know. But I will be surprised, and I
> will start questioning my life choices, for sure.
>
> > clime
> >
> > >
> > > --
> > > Aleksandra Fedorova
> > > bookwar
> > > _______________________________________________
> > > devel mailing list -- devel(a)lists.fedoraproject.org
> > > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > > 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/[e-mail]
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > 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/[e-mail]
>
> --
> Aleksandra Fedorova
> bookwar
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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/[e-mail]

[clime]

Otherwise, I think the change is a nice idea.

On Sun, 29 Mar 2020 at 16:03, clime <clime(a)fedoraproject.org&gt; wrote:
>
> On Sun, 29 Mar 2020 at 15:20, Aleksandra Fedorova <alpha(a)bookwar.info&gt; wrote:
> >
> > On Sun, Mar 29, 2020 at 2:36 PM clime <clime(a)fedoraproject.org&gt; wrote:
> > >
> > > On Sun, 29 Mar 2020 at 13:34, Aleksandra Fedorova
<alpha(a)bookwar.info&gt; wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Sat, Mar 28, 2020 at 11:25 PM clime <clime(a)fedoraproject.org&gt;
wrote:
> > > > >
> > > > > From the proposal:
> > > > >
> > > > >  %if 0%{?fedora} < 32 && 0%{?rhel} <= 8
> > > > >
> > > > > The fix will be done via a pull request that states a time limit.
We
> > > > > want the regular maintainers to see / comment / commit, but we
also
> > > > > don't want things to stall for months and get forgotten
about.
> > > > >
> > > > > ---
> > > > >
> > > > > What kind of pull request is that? It's like saying either
merge or ...
> > > > > In other words, great way to lose community members.
> > > >
> > > > This is a better version of what proven packages already do nowadays.
> > > >
> > > > If package already has a disttag-specific conditional, and this
> > > > conditional leads to a build failure in the eln-environment, then we
> > > > need a fix for that. Here we are not talking about introducing new
> > > > conditionals, feature switches or dependency adjustments. We will be
> > > > fixing the existing conditional so that package can be built.
> > > >
> > > > Currently proven packagers fix such build failures directly. We will
> > > > propose changes via pull requests, so that maintainer has a
> > > > possibility to say "no", or to say "do it
differently". But if we can
> > > > not get any feedback from a maintainer on it, we will fix the build
> > > > failure.
> > >
> > > Hi,
> > >
> > > I think it would be nice to say in the change that it's okay to say
> > > "no"
> >
> > It is a common sense. I don't see how it can be interpreted the other way.
>
> Well, the change doesn't describe concretely what to do in such a case
> except "we will talk about it or look into the options".
>
> If you said something like:
>
> "ELN SIG may opt for maintaining an ELN version of a package in a fork
> in case upstream maintainer doesn't wish to support the eln use-case."
> + technical details of this should be figured out (in terms of
> auto-syncing).
>
> It would indicate that you are ready for the situation, i.e. you are
> ready to respect a maintainers' wish.
>
> Idk, maybe you also consider this common sense or you haven't thought
> about it or something else.
>
> But I think that being more explicit in the change description could
> only help for people to understand better what it means for them.
>
> >
> > > and what
> > > ELN SIG will do in that case.
> >
> > It is described as other options in the change: We talk, we look into
> > options, we may consider removing the conditional altogether, if it is
> > not relevant anymore and continue using a clean "unconditionalized"
> > package.
> >
> > If you are asking me what I am going to do if I meet Fedora packager,
> > who deliberately _adds_ conditional to the package to make this
> > package to fail to build in the eln environment and refuses to remove
> > it, then the answer is - I don't know. But I will be surprised, and I
> > will start questioning my life choices, for sure.
> >
> > > clime
> > >
> > > >
> > > > --
> > > > Aleksandra Fedorova
> > > > bookwar
> > > > _______________________________________________
> > > > devel mailing list -- devel(a)lists.fedoraproject.org
> > > > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > > > 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/[e-mail]
> > > _______________________________________________
> > > devel mailing list -- devel(a)lists.fedoraproject.org
> > > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > > 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/[e-mail]
> >
> > --
> > Aleksandra Fedorova
> > bookwar
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > 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/[e-mail]

[Stephen John Smoogen]

On Sun, 29 Mar 2020 at 09:20, Aleksandra Fedorova <alpha(a)bookwar.info&gt;
wrote:

>  On Sun, Mar 29, 2020 at 2:36 PM clime <clime(a)fedoraproject.org&gt;
> wrote:
>  >
>  > On Sun, 29 Mar 2020 at 13:34, Aleksandra Fedorova <alpha(a)bookwar.info&gt;
>  wrote:
>  > >
>  > > Hi,
>  > >
>  > > On Sat, Mar 28, 2020 at 11:25 PM clime <clime(a)fedoraproject.org&gt;
>  wrote:
>  > > >
>
>  > Hi,
>  >
>  > I think it would be nice to say in the change that it's okay to say
>  > "no"
>
>  It is a common sense. I don't see how it can be interpreted the other way.
>
>  
As seen multiple times every day around us, what is one person's common
sense falls aside when there is stress and difficulties. Since dealing with
a lot of these things are going to be stressful, it is better to spell it
out and not assume either better angels or common sense will work when
difficulties arise.


-- 
Stephen J Smoogen.

[Petr Pisar]

On Sun, Mar 29, 2020 at 12:56:42AM +0100, clime wrote:
>  You can make a separate namespace for this in dist-git. It
> doesn't need to
>  be a separate branch. That way, you won't be disturbing anyone elses space.
>   
A different name space means a different repository. That means a full copy.
A waste of space.

By the way what about bug reports? Are we expect to use Bugzilla for the ELN
bugs? A different name space has the advatange of an independent Bugzilla
component.  Otherwise ELN bugs will get intermixed with (and default-assigned
to) the Fedora product.

-- Petr

[Vít Ondruch]

It is kind of irony, that the ELN branch idea is still rejected.
Therefore there will be PRs coming from Stephen's and Alexandra's (or
anybody else in ELN SIG) forks of packages, containing changes needed to
build some packages in ELN, which nobody is going to merge. In the
meantime, the ELN builds will keep failing.

I wonder why there can't be PR's coming from ELN branch. That would

1) Allow the ELN builds to pass.

2) Audit the work to do.

3) Give it some structure and therefore discoverability.


Just to be clear, I don't plan to accept any PR adding any "if rhel" and
similar into package I currently maintain in Fedora, sorry. Being
maintainer in Fedora and RHEL, I could have done it any time and I did
not. In every package I adopted/inherited during the years, I have
removed such conditionals, because they are PITA. While the proposal
helps with the maintenance of such conditionals, it would still harm
freedom of Fedora to innovate. I understand what is the cost and it is
not worth of it.


Vít


Dne 27. 03. 20 v 16:07 Stephen Gallagher napsal(a):
>  There has been a lot of (really good!) discussion on the original
>  proposal thread, but as it has grown too large to follow anymore, I'm
>  restarting it. I have made numerous changes to the Change Proposal
>  page to improve the scope of the proposal as well as clarify some of
>  the questions that have come up repeatedly in the original thread.
>
>  Please see the newly-updated
>  https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
>  for more details[1].
>
>  == Summary ==
>  ELN is a new buildroot and compose process for Fedora that will take
>  Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux
>  compose. Feedback from this build, compose and integration testing
>  will be provided to Fedora packagers so that they can see the
>  potential impact of their changes on RHEL development.
>
>  == Owner ==
>
>  * Name: [[User:Bookwar| Aleksandra Fedorova]]
>  * Email: alpha(a)bookwar.info
>  * Name: [[User:Sgallagh | Stephen Gallagher]]
>  * Email: sgallagh(a)redhat.com
>
>
>
>  [1] List of changes between the original and new versions:
>
> https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_C...
>  _______________________________________________
>  devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
>  To unsubscribe send an email to 
devel-announce-leave(a)lists.fedoraproject.org
>  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/[e-mail]...
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail]

[Miro Hrončok]

On 27. 03. 20 16:07, Stephen Gallagher wrote:
>  Please see the newly-updated
>  https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose 
>  Setup automation to trigger new ELN build every time there is a new
> update submitted to Fedora Rawhide. 
Put all the other feedback aside, if we actually decide that this change is 
happening, can we not build ELN during the datacenter move [1], when Koji will 
have a very limited capacity [2]?

(Either not build yet or stop the builds if they already run at that time.)

[1] https://pagure.io/fesco/issue/2221
[2] 
https://lists.fedoraproject.org/archives/list/[e-mail].o...

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Aleksandra Fedorova]

On Mon, Mar 30, 2020 at 11:11 AM Vít Ondruch <vondruch(a)redhat.com&gt; wrote:
>  It is kind of irony, that the ELN branch idea is still rejected. 
I've made several attempts to explain this decision. You are ignoring them.

>  Therefore there will be PRs coming from Stephen's and
> Alexandra's (or
>  anybody else in ELN SIG) forks of packages, containing changes needed to
>  build some packages in ELN, which nobody is going to merge. In the
>  meantime, the ELN builds will keep failing.
>
>  I wonder why there can't be PR's coming from ELN branch. That would
>
>  1) Allow the ELN builds to pass.
>
>  2) Audit the work to do.
>
>  3) Give it some structure and therefore discoverability.
>
>
>  Just to be clear, I don't plan to accept any PR adding any "if rhel" and
>  similar into package I currently maintain in Fedora, sorry. Being
>  maintainer in Fedora and RHEL, I could have done it any time and I did
>  not. In every package I adopted/inherited during the years, I have
>  removed such conditionals, because they are PITA. While the proposal
>  helps with the maintenance of such conditionals, it would still harm
>  freedom of Fedora to innovate. I understand what is the cost and it is
>  not worth of it. 
To be honest, I see a completely different kind of irony here.

For years Fedora packagers have to deal with nonresponsive upstreams.

How often we go to upstream developers, trying to convince them to
remove bundled libraries, adjust the licensing, to add a configuration
option, to split into subcomponents, to stop hardcoding docker in
their build system..
We know this struggle, we talk about it a lot, we discuss how we can
make upstream to listen to us, how we should help each other..

And then, when we play the role of the upstream, we completely forget about it.

Now, I understand people's concerns about merging some downstream
specific changes into the upstream sources without proper design or
without agreement. And we highlighted several times that we are not
going to do that.

But the fact that I need to convince Fedora packagers that they should
at least listen to the problem downstream has, and at least try to
think about how it can be addressed, through conditionals or through
refactoring, or through upstream changes.. this surprises me. I
definitely didn't expect the "don't even try to bother me with those
topics" reaction.

>  Vít
>
>
>  Dne 27. 03. 20 v 16:07 Stephen Gallagher napsal(a):
>  > There has been a lot of (really good!) discussion on the original
>  > proposal thread, but as it has grown too large to follow anymore, I'm
>  > restarting it. I have made numerous changes to the Change Proposal
>  > page to improve the scope of the proposal as well as clarify some of
>  > the questions that have come up repeatedly in the original thread.
>  >
>  > Please see the newly-updated
>  > https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
>  > for more details[1].
>  >
>  > == Summary ==
>  > ELN is a new buildroot and compose process for Fedora that will take
>  > Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux
>  > compose. Feedback from this build, compose and integration testing
>  > will be provided to Fedora packagers so that they can see the
>  > potential impact of their changes on RHEL development.
>  >
>  > == Owner ==
>  >
>  > * Name: [[User:Bookwar| Aleksandra Fedorova]]
>  > * Email: alpha(a)bookwar.info
>  > * Name: [[User:Sgallagh | Stephen Gallagher]]
>  > * Email: sgallagh(a)redhat.com
>  >
>  >
>  >
>  > [1] List of changes between the original and new versions:
>  >
> https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_C...
>  > _______________________________________________
>  > devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
>  > To unsubscribe send an email to
>  devel-announce-leave(a)lists.fedoraproject.org
>  > 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/[e-mail]...
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  > 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/[e-mail]
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail] 
-- 
Aleksandra Fedorova
bookwar

[Aleksandra Fedorova]

Hi, Miro,

On Mon, Mar 30, 2020 at 12:09 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  On 27. 03. 20 16:07, Stephen Gallagher wrote:
>  > Please see the newly-updated
>  > https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
>
>  > Setup automation to trigger new ELN build every time there is a new update submitted
> to Fedora Rawhide.
>
>  Put all the other feedback aside, if we actually decide that this change is
>  happening, can we not build ELN during the datacenter move [1], when Koji will
>  have a very limited capacity [2]? 
I think we should go with Kevin's suggestion and deprioritize eln
builds from the start. If this is not going to be enough for the
datacenter move, then we can disable ELN pipelines for two weeks.
As we will use external service (most likely Jenkins pipeline) to
trigger the builds, we will be able to switch them on and off without
changing anything on the infrastructure.

>  (Either not build yet or stop the builds if they already run at that time.)
>
>  [1] https://pagure.io/fesco/issue/2221
>  [2]
>
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>
>  --
>  Miro Hrončok
>  --
>  Phone: [phone]
>  IRC: mhroncok
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail] 
-- 
Aleksandra Fedorova
bookwar

[Miro Hrončok]

On 30. 03. 20 12:54, Aleksandra Fedorova wrote:
>  But the fact that I need to convince Fedora packagers that they
> should
>  at least listen to the problem downstream has, and at least try to
>  think about how it can be addressed, through conditionals or through
>  refactoring, or through upstream changes.. this surprises me. I
>  definitely didn't expect the "don't even try to bother me with those
>  topics" reaction. 
The problem here is that you read our feedback as "don't even try to bother me 
with those topics" while we say "the way you want to handle this is not working

for (a substantial part of) the Fedora community".

As long as you keep focusing on the "you are wrong by not wanting this" instead

of "how do we make it work for you", this discussion will not move anywhere.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Miro Hrončok]

On 30. 03. 20 12:59, Aleksandra Fedorova wrote:
> > Put all the other feedback aside, if we actually decide that this
> change is
> > happening, can we not build ELN during the datacenter move [1], when Koji will
> > have a very limited capacity [2]?
>  I think we should go with Kevin's suggestion and deprioritize eln
>  builds from the start. 
I'm afraid that this won't be good enough. Other (Fedora) builds will be 
submitted with lower prio as well. For example our Python 3.N+1 rebuilds are 
usually submitted as such, so the wave of 3k packages doesn't block individual 
packagers. So unless Koji has multiple levels of priorities, I would have 2 choices:

  - do --background and be blocked by ELN
  - don't do --background and block individual packagers

I think the automatic ELN builds should be disabled during the datacenter move 
(and it might be easier to actually wait for the move before the builds even 
start, if that's doable on schedule).

>  If this is not going to be enough for the
>  datacenter move, then we can disable ELN pipelines for two weeks.
>  As we will use external service (most likely Jenkins pipeline) to
>  trigger the builds, we will be able to switch them on and off without
>  changing anything on the infrastructure. 
Thanks.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Aleksandra Fedorova]

Hi,

On Mon, Mar 30, 2020 at 1:13 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  On 30. 03. 20 12:59, Aleksandra Fedorova wrote:
>  >> Put all the other feedback aside, if we actually decide that this change is
>  >> happening, can we not build ELN during the datacenter move [1], when Koji will
>  >> have a very limited capacity [2]?
>  > I think we should go with Kevin's suggestion and deprioritize eln
>  > builds from the start.
>
>  I'm afraid that this won't be good enough. Other (Fedora) builds will be
>  submitted with lower prio as well. For example our Python 3.N+1 rebuilds are
>  usually submitted as such, so the wave of 3k packages doesn't block individual
>  packagers. So unless Koji has multiple levels of priorities, I would have 2 choices:
>
>    - do --background and be blocked by ELN
>    - don't do --background and block individual packagers
>
>  I think the automatic ELN builds should be disabled during the datacenter move
>  (and it might be easier to actually wait for the move before the builds even
>  start, if that's doable on schedule). 
I am not even sure that we will have the automation ready by that time.

I'd like not to wait with the change till then, because we first need
to do some preparation work, to get those infrastructure bits and
pieces - disttag, koji target, basic buildroot. Then we would do some
test runs, find issues with the process... iterate.
It will take time to even start building anything, and I'd rather not
delay this work.

But then I agree we should adjust the timeline to take datacenter move
into account.

>  > If this is not going to be enough for the
>  > datacenter move, then we can disable ELN pipelines for two weeks.
>  > As we will use external service (most likely Jenkins pipeline) to
>  > trigger the builds, we will be able to switch them on and off without
>  > changing anything on the infrastructure.
>
>  Thanks.
>
>  --
>  Miro Hrončok
>  --
>  Phone: [phone]
>  IRC: mhroncok
>  
-- 
Aleksandra Fedorova
bookwar

[Petr Pisar]

On Mon, Mar 30, 2020 at 11:10:17AM +0200, Vít Ondruch wrote:
>  It is kind of irony, that the ELN branch idea is still rejected.
>  Therefore there will be PRs coming from Stephen's and Alexandra's (or
>  anybody else in ELN SIG) forks of packages, containing changes needed to
>  build some packages in ELN, which nobody is going to merge. In the
>  meantime, the ELN builds will keep failing.
>  
>  I wonder why there can't be PR's coming from ELN branch. That would
>  
>  1) Allow the ELN builds to pass.
>   
If I undeestand the proposal correctly there there will be an ELN branch or
a name space. But not by default. Only for those packages that reject the
change in Fedora.

I'm more curious what will happen with the ELN branch once the change is
merged into Fedora's master. Will the ELN branch be removed? Will the ELN branch
be reset to Fedora's master indefinetely and automatically? Or will be
stalled and once ELN maintainer needs a new change he will do tricks with
three-side git merge? I'm asking because I would prefer the first approach
and because I know the second one is forbidden in Fedora's dist-git.

-- Petr

[Miro Hrončok]

On 30. 03. 20 13:52, Petr Pisar wrote:
>  If I undeestand the proposal correctly there there will be an ELN
> branch or
>  a name space. But not by default. Only for those packages that reject the
>  change in Fedora. 
I wonder where is this coming from, because that's exactly what we want and 
exactly what the change owners don't want.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Miro Hrončok]

On 30. 03. 20 13:52, Petr Pisar wrote:
>  I'm more curious what will happen with the ELN branch once the
> change is
>  merged into Fedora's master. Will the ELN branch be removed? Will the ELN branch
>  be reset to Fedora's master indefinetely and automatically? Or will be
>  stalled and once ELN maintainer needs a new change he will do tricks with
>  three-side git merge? I'm asking because I would prefer the first approach
>  and because I know the second one is forbidden in Fedora's dist-git. 
This is exactly why Pull Request from a branch that cannot be rebased are a bad 
idea. So yes, there might be an eln branch (that's not really relevant here), 
but PRs should be done from forks as usual.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Tomas Orsava]

On 3/30/20 12:54 PM, Aleksandra Fedorova wrote:
>  On Mon, Mar 30, 2020 at 11:11 AM Vít Ondruch
> <vondruch(a)redhat.com&gt; wrote:
> > It is kind of irony, that the ELN branch idea is still rejected.
>  I've made several attempts to explain this decision. You are ignoring them.
>
> > Therefore there will be PRs coming from Stephen's and Alexandra's (or
> > anybody else in ELN SIG) forks of packages, containing changes needed to
> > build some packages in ELN, which nobody is going to merge. In the
> > meantime, the ELN builds will keep failing.
> >
> > I wonder why there can't be PR's coming from ELN branch. That would
> >
> > 1) Allow the ELN builds to pass.
> >
> > 2) Audit the work to do.
> >
> > 3) Give it some structure and therefore discoverability.
> >
> >
> > Just to be clear, I don't plan to accept any PR adding any "if rhel"
> and
> > similar into package I currently maintain in Fedora, sorry. Being
> > maintainer in Fedora and RHEL, I could have done it any time and I did
> > not. In every package I adopted/inherited during the years, I have
> > removed such conditionals, because they are PITA. While the proposal
> > helps with the maintenance of such conditionals, it would still harm
> > freedom of Fedora to innovate. I understand what is the cost and it is
> > not worth of it.
>  To be honest, I see a completely different kind of irony here.
>
>  For years Fedora packagers have to deal with nonresponsive upstreams.
>
>  How often we go to upstream developers, trying to convince them to
>  remove bundled libraries, adjust the licensing, to add a configuration
>  option, to split into subcomponents, to stop hardcoding docker in
>  their build system..
>  We know this struggle, we talk about it a lot, we discuss how we can
>  make upstream to listen to us, how we should help each other.. 

The changes you list benefit upstream (as well as downstream), so of 
course it's reasonable to merge them there.
But I don't think anyone of us expects upstreams to merge 
downstream-only changes. And that's exactly what you're proposing. So 
this argument feels a bit disingenuous to me.

Tomas

>  And then, when we play the role of the upstream, we completely forget about it.
>
>  Now, I understand people's concerns about merging some downstream
>  specific changes into the upstream sources without proper design or
>  without agreement. And we highlighted several times that we are not
>  going to do that.
>
>  But the fact that I need to convince Fedora packagers that they should
>  at least listen to the problem downstream has, and at least try to
>  think about how it can be addressed, through conditionals or through
>  refactoring, or through upstream changes.. this surprises me. I
>  definitely didn't expect the "don't even try to bother me with those
>  topics" reaction.
>
> > Vít
> >
> >
> > Dne 27. 03. 20 v 16:07 Stephen Gallagher napsal(a):
> >> There has been a lot of (really good!) discussion on the original
> >> proposal thread, but as it has grown too large to follow anymore, I'm
> >> restarting it. I have made numerous changes to the Change Proposal
> >> page to improve the scope of the proposal as well as clarify some of
> >> the questions that have come up repeatedly in the original thread.
> >>
> >> Please see the newly-updated
> >> https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
> >> for more details[1].
> >>
> >> == Summary ==
> >> ELN is a new buildroot and compose process for Fedora that will take
> >> Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux
> >> compose. Feedback from this build, compose and integration testing
> >> will be provided to Fedora packagers so that they can see the
> >> potential impact of their changes on RHEL development.
> >>
> >> == Owner ==
> >>
> >> * Name: [[User:Bookwar| Aleksandra Fedorova]]
> >> * Email: alpha(a)bookwar.info
> >> * Name: [[User:Sgallagh | Stephen Gallagher]]
> >> * Email: sgallagh(a)redhat.com
> >>
> >>
> >>
> >> [1] List of changes between the original and new versions:
> >>
> https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_C...
> >> _______________________________________________
> >> devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
> >> To unsubscribe send an email to
> > devel-announce-leave(a)lists.fedoraproject.org
> >> 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/[e-mail]...
> >> _______________________________________________
> >> devel mailing list -- devel(a)lists.fedoraproject.org
> >> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> >> 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/[e-mail]
> >
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > 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/[e-mail]

[Petr Pisar]

On Mon, Mar 30, 2020 at 01:57:22PM +0200, Miro Hrončok wrote:
>  On 30. 03. 20 13:52, Petr Pisar wrote:
>  > If I undeestand the proposal correctly there there will be an ELN branch or
>  > a name space. But not by default. Only for those packages that reject the
>  > change in Fedora.
>  
>  I wonder where is this coming from, because that's exactly what we want and
>  exactly what the change owners don't want.
>   
That's my impression from Alexandra's replies. I think she wrote that
packages
that must significantly differ from Fedora will have an ELN override. So
I conclude their sources must be somewhere stored. And since Koji does not
allow building from a non-dist-git, It must be in the dist-git.

I frankly cannot see how the create-a-pull-request-and-wait-for-the-merge
procedure would scale if the ELN maintainer would need to adjust more than
a few packages.

The easiest way would be probably allow building ELN from pull-requests. But
the maintainability would be terrible.

-- Petr

[Tomas Orsava]

On 3/30/20 2:33 PM, Petr Pisar wrote:
>  On Mon, Mar 30, 2020 at 01:57:22PM +0200, Miro Hrončok wrote:
> > On 30. 03. 20 13:52, Petr Pisar wrote:
> >> If I undeestand the proposal correctly there there will be an ELN branch or
> >> a name space. But not by default. Only for those packages that reject the
> >> change in Fedora.
> > I wonder where is this coming from, because that's exactly what we want and
> > exactly what the change owners don't want.
> >
>  That's my impression from Alexandra's replies. I think she wrote that packages
>  that must significantly differ from Fedora will have an ELN override. So
>  I conclude their sources must be somewhere stored. And since Koji does not
>  allow building from a non-dist-git, It must be in the dist-git. 

The way I understood it, the "ELN override" Alexandra described was 
using `%if %rhel` (or sometimes `%if %eln`) conditionals directly on the 
master branch.

Tomas


>  I frankly cannot see how the create-a-pull-request-and-wait-for-the-merge
>  procedure would scale if the ELN maintainer would need to adjust more than
>  a few packages.
>
>  The easiest way would be probably allow building ELN from pull-requests. But
>  the maintainability would be terrible.
>
>  -- Petr
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail]

[Kevin Fenzi]

On Mon, Mar 30, 2020 at 01:13:03PM +0200, Miro Hrončok wrote:
>  
>  I'm afraid that this won't be good enough. Other (Fedora) builds will be
>  submitted with lower prio as well. For example our Python 3.N+1 rebuilds are
>  usually submitted as such, so the wave of 3k packages doesn't block
>  individual packagers. So unless Koji has multiple levels of priorities, I 
It does. 

        priority: the amount to increase (or decrease) the task priority, relative
                  to the default priority; higher values mean lower priority; only
                  admins have the right to specify a negative priority here

It's basically an integer. 
createrepos/newRepo are 14
releng runroot jobs are 15
'normal' builds are around 19
'scratch' builds are around 20
backgrounds is 25
koschei sets it's builds to 50

kevin

[Robbie Harwood]

Petr Pisar <ppisar(a)redhat.com&gt; writes:

>  On Sun, Mar 29, 2020 at 12:56:42AM +0100, clime wrote:
>
> > You can make a separate namespace for this in dist-git. It doesn't
> > need to be a separate branch. That way, you won't be disturbing
> > anyone elses space.
>
>  A different name space means a different repository. That means a full
>  copy.  A waste of space. 
Without taking a stand on which approach is better: I would hope that
our git forge is smart enough to reuse storage for the same commit
hashes.  Therefore, a fork with merges will be very low overhead.

>  By the way what about bug reports? Are we expect to use Bugzilla for
>  the ELN bugs? A different name space has the advatange of an
>  independent Bugzilla component.  Otherwise ELN bugs will get
>  intermixed with (and default-assigned to) the Fedora product. 
This is a good question, especially since this has not been resolved for
modular components either to my knowledge.

Thanks,
--Robbie

[Miro Hrončok]

On 27. 03. 20 16:07, Stephen Gallagher wrote:
>  Please see the newly-updated
>  https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
>  for more details[1]. 
Assume I have the following CI Test in Fedora:

https://src.fedoraproject.org/rpms/python-setuptools/blob/master/f/tests/...

Yet in ELN, there will be no Python 3.4 or 3.5. How do I make this section work:

     required_packages:
     - gcc
     - virtualenv
     - python27
     - python34
     - python35
     - python36
     - python37
     - python38
     - python39
     - python3-devel
     - python3-tox
     - mock
     - rpmdevtools
     - rpm-build

AFAIK there are no conditionals possible here, or are they?

One obvious solution is "ELN will inherit from rawhide, forever" but in that 
case how do I actually know whether I'm testing ELN or rawhide?

Another solution is to build all packages dragged liek this in ELN, even the 
stuff we don't intent to have in RHEL (ever). But given the state of the 
dependency graph in Fedora, that might eventually mean we need to build (close 
to) everything.

(I'm not arguing here against the change, I am actually asking how is this going 
to work.)
-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok
.

[Miro Hrončok]

On 30. 03. 20 18:35, Kevin Fenzi wrote:
>  On Mon, Mar 30, 2020 at 01:13:03PM +0200, Miro Hrončok wrote:
> >
> > I'm afraid that this won't be good enough. Other (Fedora) builds will be
> > submitted with lower prio as well. For example our Python 3.N+1 rebuilds are
> > usually submitted as such, so the wave of 3k packages doesn't block
> > individual packagers. So unless Koji has multiple levels of priorities, I
>  
>  It does.
>  
>           priority: the amount to increase (or decrease) the task priority, relative
>                     to the default priority; higher values mean lower priority; only
>                     admins have the right to specify a negative priority here
>  
>  It's basically an integer.
>  createrepos/newRepo are 14
>  releng runroot jobs are 15
>  'normal' builds are around 19
>  'scratch' builds are around 20
>  backgrounds is 25
>  koschei sets it's builds to 50 
Oh! Great. In that case, I think we can solve this somehow if needed.

How can I submit a build with a different number? Becasue neither fedpkg build 
--help nor koji build --help seem to talk about this.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Kevin Fenzi]

On Mon, Mar 30, 2020 at 08:10:30PM +0200, Miro Hrončok wrote:
>  On 30. 03. 20 18:35, Kevin Fenzi wrote:
>  > On Mon, Mar 30, 2020 at 01:13:03PM +0200, Miro Hrončok wrote:
>  > > 
>  > > I'm afraid that this won't be good enough. Other (Fedora) builds will
> be
>  > > submitted with lower prio as well. For example our Python 3.N+1 rebuilds are
>  > > usually submitted as such, so the wave of 3k packages doesn't block
>  > > individual packagers. So unless Koji has multiple levels of priorities, I
>  > 
>  > It does.
>  > 
>  >          priority: the amount to increase (or decrease) the task priority, relative
>  >                    to the default priority; higher values mean lower priority; only
>  >                    admins have the right to specify a negative priority here
>  > 
>  > It's basically an integer.
>  > createrepos/newRepo are 14
>  > releng runroot jobs are 15
>  > 'normal' builds are around 19
>  > 'scratch' builds are around 20
>  > backgrounds is 25
>  > koschei sets it's builds to 50
>  
>  Oh! Great. In that case, I think we can solve this somehow if needed.
>  
>  How can I submit a build with a different number? Becasue neither fedpkg
>  build --help nor koji build --help seem to talk about this. 
There's koji set-task-priority, which should work. 

I don't see a way to set it on build submit... 

kevin