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

[Stephen Gallagher]

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

I've just published a fourth version[1] of the ELN proposal. With a
lot of input from Miro Hrončok, I think I've finally been able to
clarify some of the points that we were getting hung up on.

Changes in this version of the proposal[2]:

* Improve our explanation of why we are doing ELN in the first place
* Clarify the relationship with Rawhide
* Better describe what happens if packages don't build on ELN
* Explain our plan for when to use conditionals (this was getting a
larger share of the conversation than it warranted because we didn't
do a good job of explaining that they should be the exception and not
the rule)
* Clarify that the time limit on PRs is only for determining if the
maintainer is responsive. If they reply, the timer is cleared.
* Fixed the question about upstream features to make it clear that
what we meant is that new features should go upstream first, not be
implemented as a fork in ELN
* Added a section explaining how we will deal with side-tags
* Make it clear that we don't want to diverge wherever possible and
that any planned divergence should be discussed with the ELN SIG ahead
of time
* Cleaned up the contingency plan section.

I hope that these changes will make our position more clear. Thank you
to everyone who has contributed to this discussion. I think the
feedback has been very valuable and I sincerely appreciate it.



[1] https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
[2]
https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_C...
> -----BEGIN PGP SIGNATURE-----
>
> iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl6LpNgACgkQRduFpWgo
> bRH4MAwAu1INM0mplL1yQiW2DMS148VubU5DkxRbaE3biZTvw5WzzbpxwpXr+nFp
> eZf7IUyn5HCdtCAk1TQ4ga/TuV5VsaEEZ+a9p8PZfs4XTEMGpB7olP0Z8Jq1PWwn
> EM6+4BAUWJ4JS7Q1+/CnEkUHA+1ZVeAzeb5bfSlcae2Vgx6evQMB4rEqAXdr16Qk
> 3Hi082+4SutmBv67cRA/JdRZmvUaHYtS4y5DrWAXOS23k8SHUCT/2O2f7NRPAoG/
> f+04nG5JyUePY64pnVtDnsVMwETWiNSSs4V1dbKYe9Fj5H/jbvKIsvo8AWxw4BAq
> rXCSIB3wMf08eM2KTaLvk0x+cz2BiSEZEDVdceffVXMwnUZulu/oeYDKdQg9OoHW
> IQJbMoASgxRUXH1ZiMy8Q3SgQHvcu/YLmjS+djlVakLunhW7NfQjZB7txMyDi0PY
> Hwn32C1kXnaoBJds4zB4QpWiJy5wI82CRL92Zvz0kiRPiO9TMCuj+t5kLZVmVTnI
> 8ShPIeos
> =+lwN
> -----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]...

[Neal Gompa]

On Mon, Apr 6, 2020 at 5:56 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA256
>
>  I've just published a fourth version[1] of the ELN proposal. With a
>  lot of input from Miro Hrončok, I think I've finally been able to
>  clarify some of the points that we were getting hung up on.
>
>  Changes in this version of the proposal[2]:
>
>  * Improve our explanation of why we are doing ELN in the first place
>  * Clarify the relationship with Rawhide
>  * Better describe what happens if packages don't build on ELN
>  * Explain our plan for when to use conditionals (this was getting a
>  larger share of the conversation than it warranted because we didn't
>  do a good job of explaining that they should be the exception and not
>  the rule)
>  * Clarify that the time limit on PRs is only for determining if the
>  maintainer is responsive. If they reply, the timer is cleared.
>  * Fixed the question about upstream features to make it clear that
>  what we meant is that new features should go upstream first, not be
>  implemented as a fork in ELN
>  * Added a section explaining how we will deal with side-tags
>  * Make it clear that we don't want to diverge wherever possible and
>  that any planned divergence should be discussed with the ELN SIG ahead
>  of time
>  * Cleaned up the contingency plan section.
>
>  I hope that these changes will make our position more clear. Thank you
>  to everyone who has contributed to this discussion. I think the
>  feedback has been very valuable and I sincerely appreciate it.
>  
This version of the proposal is nearly perfect, in my view.

There are a couple of things I think should change:

* The DistTag should be versioned. Either .eln.elX (e.g. .eln.el9),
.elnX (e.g. .eln9), or just plain .elX (e.g. .el9).
* Likewise, I think the Koji tags should be versioned too.

I've personally been burned enough times by not having versioned
DistTags for personal rebuilds that I would strongly suggest you
reconsider having unversioned ones.

Finally, there is no adequate explanation for why ELN content can't go
out to the mirrors like Rawhide content does. I'd vastly prefer that
simply to have similar levels of availability as consumers of ELN
content. I would prefer seeing it go to the mirror network like
everything else.

Beyond that, this looks pretty good! Thanks for listening and
incorporating everyone's feedback!



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

[Miro Hrončok]

On 07. 04. 20 0:08, Neal Gompa wrote:
>  This version of the proposal is nearly perfect, in my view.
>  
>  There are a couple of things I think should change:
>  
>  * The DistTag should be versioned. Either .eln.elX (e.g. .eln.el9),
>  .elnX (e.g. .eln9), or just plain .elX (e.g. .el9). 
The good thing is that both:

   .eln.el9 > .eln
   .eln9 > .eln

So the two of the three mentioned schemes can be eventually enabled later 
without a sorting problem.

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

[Stephen Gallagher]

On Mon, Apr 6, 2020 at 6:09 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:

>  On Mon, Apr 6, 2020 at 5:56 PM Stephen Gallagher
> <sgallagh(a)redhat.com&gt;
>  wrote:
>  >
>  > -----BEGIN PGP SIGNED MESSAGE-----
>  > Hash: SHA256
>  >
>  > I've just published a fourth version[1] of the ELN proposal. With a
>  > lot of input from Miro Hrončok, I think I've finally been able to
>  > clarify some of the points that we were getting hung up on.
>  >
>  > Changes in this version of the proposal[2]:
>  >
>  > * Improve our explanation of why we are doing ELN in the first place
>  > * Clarify the relationship with Rawhide
>  > * Better describe what happens if packages don't build on ELN
>  > * Explain our plan for when to use conditionals (this was getting a
>  > larger share of the conversation than it warranted because we didn't
>  > do a good job of explaining that they should be the exception and not
>  > the rule)
>  > * Clarify that the time limit on PRs is only for determining if the
>  > maintainer is responsive. If they reply, the timer is cleared.
>  > * Fixed the question about upstream features to make it clear that
>  > what we meant is that new features should go upstream first, not be
>  > implemented as a fork in ELN
>  > * Added a section explaining how we will deal with side-tags
>  > * Make it clear that we don't want to diverge wherever possible and
>  > that any planned divergence should be discussed with the ELN SIG ahead
>  > of time
>  > * Cleaned up the contingency plan section.
>  >
>  > I hope that these changes will make our position more clear. Thank you
>  > to everyone who has contributed to this discussion. I think the
>  > feedback has been very valuable and I sincerely appreciate it.
>  >
>
>  This version of the proposal is nearly perfect, in my view.
>
>  There are a couple of things I think should change:
>
>  * The DistTag should be versioned. Either .eln.elX (e.g. .eln.el9),
>  .elnX (e.g. .eln9), or just plain .elX (e.g. .el9).
>  * Likewise, I think the Koji tags should be versioned too.
>
>  I've personally been burned enough times by not having versioned
>  DistTags for personal rebuilds that I would strongly suggest you
>  reconsider having unversioned ones.
>  

Would you mind explaining some of the situations in which you were burned?
I’m not ruling this out, but I’d like a clear justification if we were to
change something.



>  Finally, there is no adequate explanation for why ELN content
> can't go
>  out to the mirrors like Rawhide content does. I'd vastly prefer that
>  simply to have similar levels of availability as consumers of ELN
>  content. I would prefer seeing it go to the mirror network like
>  everything else. 


It’s not so much that it *cannot* as that we are trying not to overload the
mirror network with content not useful to non-developers.



>  Beyond that, this looks pretty good! Thanks for listening and
>  incorporating everyone's feedback!
>  
Thanks!


>  --
>  真実はいつも一つ！/ Always, there's only one truth!
>  _______________________________________________
>  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]
>

[Neal Gompa]

On Mon, Apr 6, 2020 at 6:22 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  On Mon, Apr 6, 2020 at 6:09 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
> >
> > * The DistTag should be versioned. Either .eln.elX (e.g. .eln.el9),
> > .elnX (e.g. .eln9), or just plain .elX (e.g. .el9).
> > * Likewise, I think the Koji tags should be versioned too.
> >
> > I've personally been burned enough times by not having versioned
> > DistTags for personal rebuilds that I would strongly suggest you
> > reconsider having unversioned ones.
>
>  Would you mind explaining some of the situations in which you were burned? I’m not ruling
> this out, but I’d like a clear justification if we were to change something.
>  
So, prior to me building my packages in OBS and getting auto-bumping
Releases, I used to bump into issues all the time with building
openSUSE packages in an environment like Koji's, where the NVR is the
key for a unique package. openSUSE does *not* define a DistTag or the
%dist variable, so %{?dist} evaluates to nothing. If you're doing
rebuilds of your packages with no source changes from one release of
openSUSE to the next, or rebuilding for new Tumbleweed snapshots,
you're going to get collisions all the time, and builds will just fail
because the NVR already exists.

This is utter chaos and you *really* don't want that problem on your
hands. Having the freedom to do a rebuild cycle for ELN whenever you
want to rebootstrap to a new major without changing sources is a
hugely valuable thing to be able to do.

And honestly, I expect the ELN tree to exist for a long time once it's
in Fedora. So some of this is also planning for a future where we
always have Fedora ELN along with Rawhide and regular Fedora stable
releases.

What I'm confused about is the hangup with versioning the ELN tree.
Why is this a problem?

> >
> > Finally, there is no adequate explanation for why ELN content can't go
> > out to the mirrors like Rawhide content does. I'd vastly prefer that
> > simply to have similar levels of availability as consumers of ELN
> > content. I would prefer seeing it go to the mirror network like
> > everything else.
>
>
>
>  It’s not so much that it *cannot* as that we are trying not to overload the mirror
> network with content not useful to non-developers.
>  
Unless you plan to get Red Hat to do CDN delivery of ELN, I think
you're going to want it on the mirror network anyway. Ultimately,
contributors like myself need to be able to *use* the content, and not
having it delivered via the mirror network means that it's going to be
painful for a large cross-section of contributors and developers.


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

[Aleksandra Fedorova]

Hi, Neal,

On Tue, Apr 7, 2020 at 12:49 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Mon, Apr 6, 2020 at 6:22 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  >
>  >
>  >
>  > On Mon, Apr 6, 2020 at 6:09 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  >>
>  >> * The DistTag should be versioned. Either .eln.elX (e.g. .eln.el9),
>  >> .elnX (e.g. .eln9), or just plain .elX (e.g. .el9).
>  >> * Likewise, I think the Koji tags should be versioned too.
>  >>
>  >> I've personally been burned enough times by not having versioned
>  >> DistTags for personal rebuilds that I would strongly suggest you
>  >> reconsider having unversioned ones.
>  >
>  > Would you mind explaining some of the situations in which you were burned? I’m not
> ruling this out, but I’d like a clear justification if we were to change something.
>  >
>
>  So, prior to me building my packages in OBS and getting auto-bumping
>  Releases, I used to bump into issues all the time with building
>  openSUSE packages in an environment like Koji's, where the NVR is the
>  key for a unique package. openSUSE does *not* define a DistTag or the
>  %dist variable, so %{?dist} evaluates to nothing. If you're doing
>  rebuilds of your packages with no source changes from one release of
>  openSUSE to the next, or rebuilding for new Tumbleweed snapshots,
>  you're going to get collisions all the time, and builds will just fail
>  because the NVR already exists.
>
>  This is utter chaos and you *really* don't want that problem on your
>  hands. Having the freedom to do a rebuild cycle for ELN whenever you
>  want to rebootstrap to a new major without changing sources is a
>  hugely valuable thing to be able to do.
>
>  And honestly, I expect the ELN tree to exist for a long time once it's
>  in Fedora. So some of this is also planning for a future where we
>  always have Fedora ELN along with Rawhide and regular Fedora stable
>  releases.
>
>  What I'm confused about is the hangup with versioning the ELN tree.
>  Why is this a problem? 
I explained it in one of the previous threads:

https://lists.fedoraproject.org/archives/list/[e-mail].o...

But I guess we need to extend this conversion by answering:
1) versioning of what exactly?
2) versioning by which number?

From the problem you describe, it looks like the solution for it is to
have %{?dist} resolved to a versioned data. But the versioning here
should be independent from both RHEL and Fedora versioning. It should
be based on changes in eln buildroot configuration itself: As soon as
we want to have a non-disruptive rebuild in eln buildroot, we
increment the number in %{?dist} for eln, and rebuild the same srpm.
And this action is not linked to Fedora or RHEL releases. This number
may as well be the date, or a simple counter.

If we do versioning in this way, then it resolves both concerns I had
in my reply there:
1) we don't try to link to particular RHEL release;
2) we don't version the koji tag and target, and we don't need to
update Koji configuration every time Fedora creates a branch. Thus the
pipelines we create for building eln packages can still be
unversioned.

>  >
>  >>
>  >> Finally, there is no adequate explanation for why ELN content can't go
>  >> out to the mirrors like Rawhide content does. I'd vastly prefer that
>  >> simply to have similar levels of availability as consumers of ELN
>  >> content. I would prefer seeing it go to the mirror network like
>  >> everything else.
>  >
>  >
>  >
>  > It’s not so much that it *cannot* as that we are trying not to overload the mirror
> network with content not useful to non-developers.
>  >
>
>  Unless you plan to get Red Hat to do CDN delivery of ELN, I think
>  you're going to want it on the mirror network anyway. Ultimately,
>  contributors like myself need to be able to *use* the content, and not
>  having it delivered via the mirror network means that it's going to be
>  painful for a large cross-section of contributors and developers.
>  
-- 
Aleksandra Fedorova
bookwar

[Miro Hrončok]

On 07. 04. 20 12:18, Aleksandra Fedorova wrote:
> > What I'm confused about is the hangup with versioning the ELN
> tree.
> > Why is this a problem?
>  I explained it in one of the previous threads:
>  
>
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>  
>  But I guess we need to extend this conversion by answering:
>  1) versioning of what exactly?
>  2) versioning by which number?
>  
>   From the problem you describe, it looks like the solution for it is to
>  have %{?dist} resolved to a versioned data. But the versioning here
>  should be independent from both RHEL and Fedora versioning. It should
>  be based on changes in eln buildroot configuration itself: As soon as
>  we want to have a non-disruptive rebuild in eln buildroot, we
>  increment the number in %{?dist} for eln, and rebuild the same srpm.
>  And this action is not linked to Fedora or RHEL releases. This number
>  may as well be the date, or a simple counter.
>  
>  If we do versioning in this way, then it resolves both concerns I had
>  in my reply there:
>  1) we don't try to link to particular RHEL release;
>  2) we don't version the koji tag and target, and we don't need to
>  update Koji configuration every time Fedora creates a branch. Thus the
>  pipelines we create for building eln packages can still be
>  unversioned. 

What you say here is very inconsistent with %{eln} and %{rhel} value. In 
particular "the versioning here should be independent from RHEL" and "we
don't 
try to link to particular RHEL release" is very weird considering that %{eln} 
and %{rhel} will evaluate to "next RHEL version".

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

[Aleksandra Fedorova]

Hi,

On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  On 07. 04. 20 12:18, Aleksandra Fedorova wrote:
>  >> What I'm confused about is the hangup with versioning the ELN tree.
>  >> Why is this a problem?
>  > I explained it in one of the previous threads:
>  >
>  >
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>  >
>  > But I guess we need to extend this conversion by answering:
>  > 1) versioning of what exactly?
>  > 2) versioning by which number?
>  >
>  >  From the problem you describe, it looks like the solution for it is to
>  > have %{?dist} resolved to a versioned data. But the versioning here
>  > should be independent from both RHEL and Fedora versioning. It should
>  > be based on changes in eln buildroot configuration itself: As soon as
>  > we want to have a non-disruptive rebuild in eln buildroot, we
>  > increment the number in %{?dist} for eln, and rebuild the same srpm.
>  > And this action is not linked to Fedora or RHEL releases. This number
>  > may as well be the date, or a simple counter.
>  >
>  > If we do versioning in this way, then it resolves both concerns I had
>  > in my reply there:
>  > 1) we don't try to link to particular RHEL release;
>  > 2) we don't version the koji tag and target, and we don't need to
>  > update Koji configuration every time Fedora creates a branch. Thus the
>  > pipelines we create for building eln packages can still be
>  > unversioned.
>
>
>  What you say here is very inconsistent with %{eln} and %{rhel} value. In
>  particular "the versioning here should be independent from RHEL" and "we
> don't
>  try to link to particular RHEL release" is very weird considering that %{eln}
>  and %{rhel} will evaluate to "next RHEL version". 
You are right. Originally we were thinking of %{eln} as a boolean,
rather than a meaningful data. So the important part was that we set
it to something, so that in those very rare cases where we may want to
have a condition based on eln, we can use it.
We defined %{eln} to be "something", and that something just happened
to be %{rhel}.

But since we are talking about versioning for eln now, it makes sense
to use this macro to store the actual data about eln buildroot.

So I am thinking of adjusting the change in the following form:

----
* %{rhel} will be set and will return a number one higher than the
most recent major release of Red Hat Enterprise Linux (at present,
that will be 9).
* %{eln} will be set and will expand to the ELN version (independent
of Fedora and RHEL) in a format "X.Y".  X will be bumped for mass
rebuilds, Y - for other changes.
* %{dist} will be set to "eln%{eln}"

Explicit usage of %{eln} macro in spec files should be discouraged. As
its main purpose is the versioning of the build environment, not
adjusting the sources.
----

This way we can experiment with the configuration ELN-buildroot
without bumping package sources.

And we will have RHEL versioning available, but not directly, which
adds some flexibility in relation between ELN and RHEL.



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

[Neal Gompa]

On Tue, Apr 7, 2020 at 1:50 PM Aleksandra Fedorova <alpha(a)bookwar.info&gt; wrote:
>  Hi,
>
>  On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  >
>  > On 07. 04. 20 12:18, Aleksandra Fedorova wrote:
>  > >> What I'm confused about is the hangup with versioning the ELN tree.
>  > >> Why is this a problem?
>  > > I explained it in one of the previous threads:
>  > >
>  > >
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>  > >
>  > > But I guess we need to extend this conversion by answering:
>  > > 1) versioning of what exactly?
>  > > 2) versioning by which number?
>  > >
>  > >  From the problem you describe, it looks like the solution for it is to
>  > > have %{?dist} resolved to a versioned data. But the versioning here
>  > > should be independent from both RHEL and Fedora versioning. It should
>  > > be based on changes in eln buildroot configuration itself: As soon as
>  > > we want to have a non-disruptive rebuild in eln buildroot, we
>  > > increment the number in %{?dist} for eln, and rebuild the same srpm.
>  > > And this action is not linked to Fedora or RHEL releases. This number
>  > > may as well be the date, or a simple counter.
>  > >
>  > > If we do versioning in this way, then it resolves both concerns I had
>  > > in my reply there:
>  > > 1) we don't try to link to particular RHEL release;
>  > > 2) we don't version the koji tag and target, and we don't need to
>  > > update Koji configuration every time Fedora creates a branch. Thus the
>  > > pipelines we create for building eln packages can still be
>  > > unversioned.
>  >
>  >
>  > What you say here is very inconsistent with %{eln} and %{rhel} value. In
>  > particular "the versioning here should be independent from RHEL" and
> "we don't
>  > try to link to particular RHEL release" is very weird considering that %{eln}
>  > and %{rhel} will evaluate to "next RHEL version".
>
>  You are right. Originally we were thinking of %{eln} as a boolean,
>  rather than a meaningful data. So the important part was that we set
>  it to something, so that in those very rare cases where we may want to
>  have a condition based on eln, we can use it.
>  We defined %{eln} to be "something", and that something just happened
>  to be %{rhel}.
>
>  But since we are talking about versioning for eln now, it makes sense
>  to use this macro to store the actual data about eln buildroot.
>
>  So I am thinking of adjusting the change in the following form:
>
>  ----
>  * %{rhel} will be set and will return a number one higher than the
>  most recent major release of Red Hat Enterprise Linux (at present,
>  that will be 9).
>  * %{eln} will be set and will expand to the ELN version (independent
>  of Fedora and RHEL) in a format "X.Y".  X will be bumped for mass
>  rebuilds, Y - for other changes.
>  * %{dist} will be set to "eln%{eln}"
>
>  Explicit usage of %{eln} macro in spec files should be discouraged. As
>  its main purpose is the versioning of the build environment, not
>  adjusting the sources.
>  ----
>
>  This way we can experiment with the configuration ELN-buildroot
>  without bumping package sources.
>
>  And we will have RHEL versioning available, but not directly, which
>  adds some flexibility in relation between ELN and RHEL.
>  
This definitely solves the issue I've been thinking of. I'm not sure I
understand why we want to disconnect the ELN version from the upcoming
RHEL version, even in the DistTag? It seems to be a weird hoop to
separate when we all know this is about building the next RHEL major,
and we all know what the next version is, and we all know the
timelines.



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

[Stephen Gallagher]

On Tue, Apr 7, 2020 at 1:56 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  This definitely solves the issue I've been thinking of. I'm
> not sure I
>  understand why we want to disconnect the ELN version from the upcoming
>  RHEL version, even in the DistTag? It seems to be a weird hoop to
>  separate when we all know this is about building the next RHEL major,
>  and we all know what the next version is, and we all know the
>  timelines. 
It's not about being cagey about the release, it's actually about us
retaining the ability to perform a rebuild without needing to push a
release-bump into the Fedora dist-git for issues that are
ELN-specific. (For example, ELN might carry a link-time-optimization
flag that we discover causes bugs to appear on certain packages. That
flag isn't used on Fedora, so we wouldn't want to bother the
maintainer with a version bump. We'd just bump the Y value of %{eln}
and resubmit it to Koji, which would then not have a duplicate NEVRA
appearing.

[Neal Gompa]

On Tue, Apr 7, 2020 at 2:02 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  On Tue, Apr 7, 2020 at 1:56 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  > This definitely solves the issue I've been thinking of. I'm not sure I
>  > understand why we want to disconnect the ELN version from the upcoming
>  > RHEL version, even in the DistTag? It seems to be a weird hoop to
>  > separate when we all know this is about building the next RHEL major,
>  > and we all know what the next version is, and we all know the
>  > timelines.
>
>  It's not about being cagey about the release, it's actually about us
>  retaining the ability to perform a rebuild without needing to push a
>  release-bump into the Fedora dist-git for issues that are
>  ELN-specific. (For example, ELN might carry a link-time-optimization
>  flag that we discover causes bugs to appear on certain packages. That
>  flag isn't used on Fedora, so we wouldn't want to bother the
>  maintainer with a version bump. We'd just bump the Y value of %{eln}
>  and resubmit it to Koji, which would then not have a duplicate NEVRA
>  appearing. 
That part I get... I mean, why not eln%{rhel}.X.Y?


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

[Aleksandra Fedorova]

On Tue, Apr 7, 2020 at 7:55 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Tue, Apr 7, 2020 at 1:50 PM Aleksandra Fedorova <alpha(a)bookwar.info&gt; wrote:
>  >
>  > Hi,
>  >
>  > On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  > >
>  > > On 07. 04. 20 12:18, Aleksandra Fedorova wrote:
>  > > >> What I'm confused about is the hangup with versioning the ELN
> tree.
>  > > >> Why is this a problem?
>  > > > I explained it in one of the previous threads:
>  > > >
>  > > >
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>  > > >
>  > > > But I guess we need to extend this conversion by answering:
>  > > > 1) versioning of what exactly?
>  > > > 2) versioning by which number?
>  > > >
>  > > >  From the problem you describe, it looks like the solution for it is to
>  > > > have %{?dist} resolved to a versioned data. But the versioning here
>  > > > should be independent from both RHEL and Fedora versioning. It should
>  > > > be based on changes in eln buildroot configuration itself: As soon as
>  > > > we want to have a non-disruptive rebuild in eln buildroot, we
>  > > > increment the number in %{?dist} for eln, and rebuild the same srpm.
>  > > > And this action is not linked to Fedora or RHEL releases. This number
>  > > > may as well be the date, or a simple counter.
>  > > >
>  > > > If we do versioning in this way, then it resolves both concerns I had
>  > > > in my reply there:
>  > > > 1) we don't try to link to particular RHEL release;
>  > > > 2) we don't version the koji tag and target, and we don't need to
>  > > > update Koji configuration every time Fedora creates a branch. Thus the
>  > > > pipelines we create for building eln packages can still be
>  > > > unversioned.
>  > >
>  > >
>  > > What you say here is very inconsistent with %{eln} and %{rhel} value. In
>  > > particular "the versioning here should be independent from RHEL" and
> "we don't
>  > > try to link to particular RHEL release" is very weird considering that
> %{eln}
>  > > and %{rhel} will evaluate to "next RHEL version".
>  >
>  > You are right. Originally we were thinking of %{eln} as a boolean,
>  > rather than a meaningful data. So the important part was that we set
>  > it to something, so that in those very rare cases where we may want to
>  > have a condition based on eln, we can use it.
>  > We defined %{eln} to be "something", and that something just happened
>  > to be %{rhel}.
>  >
>  > But since we are talking about versioning for eln now, it makes sense
>  > to use this macro to store the actual data about eln buildroot.
>  >
>  > So I am thinking of adjusting the change in the following form:
>  >
>  > ----
>  > * %{rhel} will be set and will return a number one higher than the
>  > most recent major release of Red Hat Enterprise Linux (at present,
>  > that will be 9).
>  > * %{eln} will be set and will expand to the ELN version (independent
>  > of Fedora and RHEL) in a format "X.Y".  X will be bumped for mass
>  > rebuilds, Y - for other changes.
>  > * %{dist} will be set to "eln%{eln}"
>  >
>  > Explicit usage of %{eln} macro in spec files should be discouraged. As
>  > its main purpose is the versioning of the build environment, not
>  > adjusting the sources.
>  > ----
>  >
>  > This way we can experiment with the configuration ELN-buildroot
>  > without bumping package sources.
>  >
>  > And we will have RHEL versioning available, but not directly, which
>  > adds some flexibility in relation between ELN and RHEL.
>  >
>
>  This definitely solves the issue I've been thinking of. I'm not sure I
>  understand why we want to disconnect the ELN version from the upcoming
>  RHEL version, even in the DistTag? It seems to be a weird hoop to
>  separate when we all know this is about building the next RHEL major,
>  and we all know what the next version is, and we all know the
>  timelines. 
Don't get me wrong, I am not trying to hide the fact that we are
building RHEL type of packages.

But
1) aligning those versions is a more complex task than it looks.

Historically we had this %rhel macro to map to next release version
working, because we were building Fedora content for RHEL only during
the specific phase of RHEL development, where this number is known and
fixed. Now we propose to do it _continuously_ in Fedora Rawhide. And
it is not that clear when exactly the jump of this version will
happen. Because of the continuity the mapping between eln packages and
RHEL packages is less obvious: It depends on which phase internal RHEL
development is. but more to that, it can depend on which phase the
development of a specific package is, as some packages can diverge
from upstream earlier than others.

So this eln to rhel mapping is a more complicated topic, then mapping
EPEL to RHEL for example. And we probably will have to rethink it
several times in the next couple of years.

2) we may need to bump version of the eln buildroot much more often
than RHEL does major releases.

As it comes from the use cases and the problem you have described, we
want to actively experiment with the buildroot setup. So it makes
sense to track it through versioning.

>  --
>  真実はいつも一つ！/ Always, there's only one truth!
>  _______________________________________________
>  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

[Neal Gompa]

On Tue, Apr 7, 2020 at 2:11 PM Aleksandra Fedorova <alpha(a)bookwar.info&gt; wrote:
>  On Tue, Apr 7, 2020 at 7:55 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  >
>  > On Tue, Apr 7, 2020 at 1:50 PM Aleksandra Fedorova <alpha(a)bookwar.info&gt;
> wrote:
>  > >
>  > > Hi,
>  > >
>  > > On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  > > >
>  > > > On 07. 04. 20 12:18, Aleksandra Fedorova wrote:
>  > > > >> What I'm confused about is the hangup with versioning the ELN
> tree.
>  > > > >> Why is this a problem?
>  > > > > I explained it in one of the previous threads:
>  > > > >
>  > > > >
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>  > > > >
>  > > > > But I guess we need to extend this conversion by answering:
>  > > > > 1) versioning of what exactly?
>  > > > > 2) versioning by which number?
>  > > > >
>  > > > >  From the problem you describe, it looks like the solution for it is
> to
>  > > > > have %{?dist} resolved to a versioned data. But the versioning here
>  > > > > should be independent from both RHEL and Fedora versioning. It
> should
>  > > > > be based on changes in eln buildroot configuration itself: As soon
> as
>  > > > > we want to have a non-disruptive rebuild in eln buildroot, we
>  > > > > increment the number in %{?dist} for eln, and rebuild the same srpm.
>  > > > > And this action is not linked to Fedora or RHEL releases. This
> number
>  > > > > may as well be the date, or a simple counter.
>  > > > >
>  > > > > If we do versioning in this way, then it resolves both concerns I
> had
>  > > > > in my reply there:
>  > > > > 1) we don't try to link to particular RHEL release;
>  > > > > 2) we don't version the koji tag and target, and we don't
> need to
>  > > > > update Koji configuration every time Fedora creates a branch. Thus
> the
>  > > > > pipelines we create for building eln packages can still be
>  > > > > unversioned.
>  > > >
>  > > >
>  > > > What you say here is very inconsistent with %{eln} and %{rhel} value. In
>  > > > particular "the versioning here should be independent from RHEL"
> and "we don't
>  > > > try to link to particular RHEL release" is very weird considering
> that %{eln}
>  > > > and %{rhel} will evaluate to "next RHEL version".
>  > >
>  > > You are right. Originally we were thinking of %{eln} as a boolean,
>  > > rather than a meaningful data. So the important part was that we set
>  > > it to something, so that in those very rare cases where we may want to
>  > > have a condition based on eln, we can use it.
>  > > We defined %{eln} to be "something", and that something just
> happened
>  > > to be %{rhel}.
>  > >
>  > > But since we are talking about versioning for eln now, it makes sense
>  > > to use this macro to store the actual data about eln buildroot.
>  > >
>  > > So I am thinking of adjusting the change in the following form:
>  > >
>  > > ----
>  > > * %{rhel} will be set and will return a number one higher than the
>  > > most recent major release of Red Hat Enterprise Linux (at present,
>  > > that will be 9).
>  > > * %{eln} will be set and will expand to the ELN version (independent
>  > > of Fedora and RHEL) in a format "X.Y".  X will be bumped for mass
>  > > rebuilds, Y - for other changes.
>  > > * %{dist} will be set to "eln%{eln}"
>  > >
>  > > Explicit usage of %{eln} macro in spec files should be discouraged. As
>  > > its main purpose is the versioning of the build environment, not
>  > > adjusting the sources.
>  > > ----
>  > >
>  > > This way we can experiment with the configuration ELN-buildroot
>  > > without bumping package sources.
>  > >
>  > > And we will have RHEL versioning available, but not directly, which
>  > > adds some flexibility in relation between ELN and RHEL.
>  > >
>  >
>  > This definitely solves the issue I've been thinking of. I'm not sure I
>  > understand why we want to disconnect the ELN version from the upcoming
>  > RHEL version, even in the DistTag? It seems to be a weird hoop to
>  > separate when we all know this is about building the next RHEL major,
>  > and we all know what the next version is, and we all know the
>  > timelines.
>
>  Don't get me wrong, I am not trying to hide the fact that we are
>  building RHEL type of packages.
>
>  But
>  1) aligning those versions is a more complex task than it looks.
>
>  Historically we had this %rhel macro to map to next release version
>  working, because we were building Fedora content for RHEL only during
>  the specific phase of RHEL development, where this number is known and
>  fixed. Now we propose to do it _continuously_ in Fedora Rawhide. And
>  it is not that clear when exactly the jump of this version will
>  happen. Because of the continuity the mapping between eln packages and
>  RHEL packages is less obvious: It depends on which phase internal RHEL
>  development is. but more to that, it can depend on which phase the
>  development of a specific package is, as some packages can diverge
>  from upstream earlier than others.
>
>  So this eln to rhel mapping is a more complicated topic, then mapping
>  EPEL to RHEL for example. And we probably will have to rethink it
>  several times in the next couple of years.
>
>  2) we may need to bump version of the eln buildroot much more often
>  than RHEL does major releases.
>
>  As it comes from the use cases and the problem you have described, we
>  want to actively experiment with the buildroot setup. So it makes
>  sense to track it through versioning.
>  
Makes some sense to me. I'm a bit skeptical, but the reasoning makes
sense. With that adjustment, at least from my perspective I think this
is okay.




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

[Stephen Gallagher]

On Tue, Apr 7, 2020 at 2:16 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  > > This definitely solves the issue I've been thinking of.
> I'm not sure I
>  > > understand why we want to disconnect the ELN version from the upcoming
>  > > RHEL version, even in the DistTag? It seems to be a weird hoop to
>  > > separate when we all know this is about building the next RHEL major,
>  > > and we all know what the next version is, and we all know the
>  > > timelines.
>  >
>  > Don't get me wrong, I am not trying to hide the fact that we are
>  > building RHEL type of packages.
>  >
>  > But
>  > 1) aligning those versions is a more complex task than it looks.
>  >
>  > Historically we had this %rhel macro to map to next release version
>  > working, because we were building Fedora content for RHEL only during
>  > the specific phase of RHEL development, where this number is known and
>  > fixed. Now we propose to do it _continuously_ in Fedora Rawhide. And
>  > it is not that clear when exactly the jump of this version will
>  > happen. Because of the continuity the mapping between eln packages and
>  > RHEL packages is less obvious: It depends on which phase internal RHEL
>  > development is. but more to that, it can depend on which phase the
>  > development of a specific package is, as some packages can diverge
>  > from upstream earlier than others.
>  >
>  > So this eln to rhel mapping is a more complicated topic, then mapping
>  > EPEL to RHEL for example. And we probably will have to rethink it
>  > several times in the next couple of years.
>  >
>  > 2) we may need to bump version of the eln buildroot much more often
>  > than RHEL does major releases.
>  >
>  > As it comes from the use cases and the problem you have described, we
>  > want to actively experiment with the buildroot setup. So it makes
>  > sense to track it through versioning.
>  >
>
>  Makes some sense to me. I'm a bit skeptical, but the reasoning makes
>  sense. With that adjustment, at least from my perspective I think this
>  is okay. 
The other piece of it is that there's a UX/psychological piece to it.
If we call it .eln9.1.0, people are quite likely to skim over the 'n'
and confuse themselves into thinking it's a RHEL 9.1.0 package. That
way lies a support nightmare. We absolutely agree with your assessment
that the dist tag needs to be versioned (see my earlier mail), but we
want to disambiguate it so it doesn't look like a real RHEL package.
(I'm debating starting with a higher number like 100 so it doesn't get
confused with Fedora or RHEL versions that we're likely to see any day
soon.)

[Neal Gompa]

On Tue, Apr 7, 2020 at 2:27 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  On Tue, Apr 7, 2020 at 2:16 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  > > > This definitely solves the issue I've been thinking of. I'm not
> sure I
>  > > > understand why we want to disconnect the ELN version from the upcoming
>  > > > RHEL version, even in the DistTag? It seems to be a weird hoop to
>  > > > separate when we all know this is about building the next RHEL major,
>  > > > and we all know what the next version is, and we all know the
>  > > > timelines.
>  > >
>  > > Don't get me wrong, I am not trying to hide the fact that we are
>  > > building RHEL type of packages.
>  > >
>  > > But
>  > > 1) aligning those versions is a more complex task than it looks.
>  > >
>  > > Historically we had this %rhel macro to map to next release version
>  > > working, because we were building Fedora content for RHEL only during
>  > > the specific phase of RHEL development, where this number is known and
>  > > fixed. Now we propose to do it _continuously_ in Fedora Rawhide. And
>  > > it is not that clear when exactly the jump of this version will
>  > > happen. Because of the continuity the mapping between eln packages and
>  > > RHEL packages is less obvious: It depends on which phase internal RHEL
>  > > development is. but more to that, it can depend on which phase the
>  > > development of a specific package is, as some packages can diverge
>  > > from upstream earlier than others.
>  > >
>  > > So this eln to rhel mapping is a more complicated topic, then mapping
>  > > EPEL to RHEL for example. And we probably will have to rethink it
>  > > several times in the next couple of years.
>  > >
>  > > 2) we may need to bump version of the eln buildroot much more often
>  > > than RHEL does major releases.
>  > >
>  > > As it comes from the use cases and the problem you have described, we
>  > > want to actively experiment with the buildroot setup. So it makes
>  > > sense to track it through versioning.
>  > >
>  >
>  > Makes some sense to me. I'm a bit skeptical, but the reasoning makes
>  > sense. With that adjustment, at least from my perspective I think this
>  > is okay.
>
>  The other piece of it is that there's a UX/psychological piece to it.
>  If we call it .eln9.1.0, people are quite likely to skim over the 'n'
>  and confuse themselves into thinking it's a RHEL 9.1.0 package. That
>  way lies a support nightmare. We absolutely agree with your assessment
>  that the dist tag needs to be versioned (see my earlier mail), but we
>  want to disambiguate it so it doesn't look like a real RHEL package.
>  (I'm debating starting with a higher number like 100 so it doesn't get
>  confused with Fedora or RHEL versions that we're likely to see any day
>  soon.) 
Okay then. :)


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

[Josh Boyer]

On Tue, Apr 7, 2020 at 2:27 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  On Tue, Apr 7, 2020 at 2:16 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  > > > This definitely solves the issue I've been thinking of. I'm not
> sure I
>  > > > understand why we want to disconnect the ELN version from the upcoming
>  > > > RHEL version, even in the DistTag? It seems to be a weird hoop to
>  > > > separate when we all know this is about building the next RHEL major,
>  > > > and we all know what the next version is, and we all know the
>  > > > timelines.
>  > >
>  > > Don't get me wrong, I am not trying to hide the fact that we are
>  > > building RHEL type of packages.
>  > >
>  > > But
>  > > 1) aligning those versions is a more complex task than it looks.
>  > >
>  > > Historically we had this %rhel macro to map to next release version
>  > > working, because we were building Fedora content for RHEL only during
>  > > the specific phase of RHEL development, where this number is known and
>  > > fixed. Now we propose to do it _continuously_ in Fedora Rawhide. And
>  > > it is not that clear when exactly the jump of this version will
>  > > happen. Because of the continuity the mapping between eln packages and
>  > > RHEL packages is less obvious: It depends on which phase internal RHEL
>  > > development is. but more to that, it can depend on which phase the
>  > > development of a specific package is, as some packages can diverge
>  > > from upstream earlier than others.
>  > >
>  > > So this eln to rhel mapping is a more complicated topic, then mapping
>  > > EPEL to RHEL for example. And we probably will have to rethink it
>  > > several times in the next couple of years.
>  > >
>  > > 2) we may need to bump version of the eln buildroot much more often
>  > > than RHEL does major releases.
>  > >
>  > > As it comes from the use cases and the problem you have described, we
>  > > want to actively experiment with the buildroot setup. So it makes
>  > > sense to track it through versioning.
>  > >
>  >
>  > Makes some sense to me. I'm a bit skeptical, but the reasoning makes
>  > sense. With that adjustment, at least from my perspective I think this
>  > is okay.
>
>  The other piece of it is that there's a UX/psychological piece to it.
>  If we call it .eln9.1.0, people are quite likely to skim over the 'n'
>  and confuse themselves into thinking it's a RHEL 9.1.0 package. That
>  way lies a support nightmare. We absolutely agree with your assessment
>  that the dist tag needs to be versioned (see my earlier mail), but we
>  want to disambiguate it so it doesn't look like a real RHEL package.
>  (I'm debating starting with a higher number like 100 so it doesn't get
>  confused with Fedora or RHEL versions that we're likely to see any day
>  soon.) 
I appreciate the amount of thought that went into that.  It's not
something most people even consider, and I think your concerns are
well founded.  Thanks for thinking that through!

josh

[James Cassell]

On Tue, Apr 7, 2020, at 2:42 PM, Josh Boyer wrote:
>  On Tue, Apr 7, 2020 at 2:27 PM Stephen Gallagher
> <sgallagh(a)redhat.com&gt; wrote:
>  >
>  > On Tue, Apr 7, 2020 at 2:16 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  > > > > This definitely solves the issue I've been thinking of. I'm
> not sure I
>  > > > > understand why we want to disconnect the ELN version from the
> upcoming
>  > > > > RHEL version, even in the DistTag? It seems to be a weird hoop to
>  > > > > separate when we all know this is about building the next RHEL
> major,
>  > > > > and we all know what the next version is, and we all know the
>  > > > > timelines.
>  > > >
>  > > > Don't get me wrong, I am not trying to hide the fact that we are
>  > > > building RHEL type of packages.
>  > > >
>  > > > But
>  > > > 1) aligning those versions is a more complex task than it looks.
>  > > >
>  > > > Historically we had this %rhel macro to map to next release version
>  > > > working, because we were building Fedora content for RHEL only during
>  > > > the specific phase of RHEL development, where this number is known and
>  > > > fixed. Now we propose to do it _continuously_ in Fedora Rawhide. And
>  > > > it is not that clear when exactly the jump of this version will
>  > > > happen. Because of the continuity the mapping between eln packages and
>  > > > RHEL packages is less obvious: It depends on which phase internal RHEL
>  > > > development is. but more to that, it can depend on which phase the
>  > > > development of a specific package is, as some packages can diverge
>  > > > from upstream earlier than others.
>  > > >
>  > > > So this eln to rhel mapping is a more complicated topic, then mapping
>  > > > EPEL to RHEL for example. And we probably will have to rethink it
>  > > > several times in the next couple of years.
>  > > >
>  > > > 2) we may need to bump version of the eln buildroot much more often
>  > > > than RHEL does major releases.
>  > > >
>  > > > As it comes from the use cases and the problem you have described, we
>  > > > want to actively experiment with the buildroot setup. So it makes
>  > > > sense to track it through versioning.
>  > > >
>  > >
>  > > Makes some sense to me. I'm a bit skeptical, but the reasoning makes
>  > > sense. With that adjustment, at least from my perspective I think this
>  > > is okay.
>  >
>  > The other piece of it is that there's a UX/psychological piece to it.
>  > If we call it .eln9.1.0, people are quite likely to skim over the 'n'
>  > and confuse themselves into thinking it's a RHEL 9.1.0 package. That
>  > way lies a support nightmare. We absolutely agree with your assessment
>  > that the dist tag needs to be versioned (see my earlier mail), but we
>  > want to disambiguate it so it doesn't look like a real RHEL package.
>  > (I'm debating starting with a higher number like 100 so it doesn't get
>  > confused with Fedora or RHEL versions that we're likely to see any day
>  > soon.)
>  
>  I appreciate the amount of thought that went into that.  It's not
>  something most people even consider, and I think your concerns are
>  well founded.  Thanks for thinking that through!
>   
eln9.100.0 makes the relation to RHEL cycle obvious without looking like a RHEL tag. Is
dot allowed here? Do we need eln9_100_1?

V/r,
James Cassell

[Stephen Gallagher]

On Tue, Apr 7, 2020 at 2:49 PM James Cassell
<fedoraproject(a)cyberpear.com&gt; wrote:
>  eln9.100.0 makes the relation to RHEL cycle obvious without looking
> like a RHEL tag. Is dot allowed here? Do we need eln9_100_1? 
The dots would be permissible here.

That said, can you describe what value you see in having the RHEL
cycle represented in the RPM name? (Because that's basically the only
practical effect here.) Particularly if you consider that we do not
plan to have mass-rebuilds scheduled around RHEL releases, so a
package that isn't updated for a long time after ELN starts tracking
towards RHEL 10 is going to start confusing people the same way that
having ".fc30" packages in Fedora 31 continues to do.

I'm not saying "no", I'd just like to hear a clear value justification
for carrying that number in the package name.

[Nicolas Mailhot]

Le mardi 07 avril 2020 à 14:27 -0400, Stephen Gallagher a écrit :
>  
>  The other piece of it is that there's a UX/psychological piece to it.
>  If we call it .eln9.1.0, people are quite likely to skim over the 'n'
>  and confuse themselves into thinking it's a RHEL 9.1.0 package.  
Then use .el.9.dev. That should still order mostly fine, and the dev
bit will scare away any corp user.

-- 
Nicolas Mailhot

[Miro Hrončok]

On 08. 04. 20 14:52, Nicolas Mailhot via devel wrote:
>  Then use .el.9.dev. That should still order mostly fine 
.el9~dev would sort even better.

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

[Michael Cronenworth]

On 4/7/20 1:27 PM, Stephen Gallagher wrote:
>  The other piece of it is that there's a UX/psychological piece to
> it.
>  If we call it .eln9.1.0, people are quite likely to skim over the 'n'
>  and confuse themselves into thinking it's a RHEL 9.1.0 package. That
>  way lies a support nightmare. We absolutely agree with your assessment
>  that the dist tag needs to be versioned (see my earlier mail), but we
>  want to disambiguate it so it doesn't look like a real RHEL package.
>  (I'm debating starting with a higher number like 100 so it doesn't get
>  confused with Fedora or RHEL versions that we're likely to see any day
>  soon.) 
Have you considered using $YEAR or a combo of date units? Then $YEAR could be 
automatically inserted if $DIST == ELN.

Version: 1.0
Release: 1%{?dist}

Output: foobar-1.0-1.eln2020

[Petr Pisar]

On Mon, Apr 06, 2020 at 06:48:17PM -0400, Neal Gompa wrote:
>  On Mon, Apr 6, 2020 at 6:22 PM Stephen Gallagher
> <sgallagh(a)redhat.com&gt; wrote:
>  > On Mon, Apr 6, 2020 at 6:09 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  >> I've personally been burned enough times by not having versioned
>  >> DistTags for personal rebuilds that I would strongly suggest you
>  >> reconsider having unversioned ones.
>  >
>  > Would you mind explaining some of the situations in which you were burned?
>  > I’m not ruling this out, but I’d like a clear justification if we were to
>  > change something.
>  >
>  So, prior to me building my packages in OBS and getting auto-bumping
>  Releases, I used to bump into issues all the time with building openSUSE
>  packages in an environment like Koji's, where the NVR is the key for
>  a unique package. openSUSE does *not* define a DistTag or the %dist
>  variable, so %{?dist} evaluates to nothing. If you're doing rebuilds of your
>  packages with no source changes from one release of openSUSE to the next, or
>  rebuilding for new Tumbleweed snapshots, you're going to get collisions all
>  the time, and builds will just fail because the NVR already exists.
>   
I think ELN won't have this problem (at large scale) because it will inherit
sources from Fedora where any new Fedora build has a bumped release for the
reason you described. It will resemble more a shadow Koji for the secondary
architectures.

But you are right that funny times can come when an ELN build screws things and
ELN people will have to not only untag it but also delete it from the NVR index so
that it can be rebuilt again with the same NVR. Fedora people weren't happy if
they had to add a dummy release bumps just only because of ELN.

>  This is utter chaos and you *really* don't want that problem on
> your
>  hands. Having the freedom to do a rebuild cycle for ELN whenever you
>  want to rebootstrap to a new major without changing sources is a
>  hugely valuable thing to be able to do.
>  
I think they will just throw it away and start from the scratch. At the end
they would like to rebuild all the packages with the new configuration.

-- Petr

[Neal Gompa]

On Tue, Apr 7, 2020 at 7:33 AM Petr Pisar <ppisar(a)redhat.com&gt; wrote:
>  On Mon, Apr 06, 2020 at 06:48:17PM -0400, Neal Gompa wrote:
>  > On Mon, Apr 6, 2020 at 6:22 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  > > On Mon, Apr 6, 2020 at 6:09 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  > >> I've personally been burned enough times by not having versioned
>  > >> DistTags for personal rebuilds that I would strongly suggest you
>  > >> reconsider having unversioned ones.
>  > >
>  > > Would you mind explaining some of the situations in which you were burned?
>  > > I’m not ruling this out, but I’d like a clear justification if we were to
>  > > change something.
>  > >
>  > So, prior to me building my packages in OBS and getting auto-bumping
>  > Releases, I used to bump into issues all the time with building openSUSE
>  > packages in an environment like Koji's, where the NVR is the key for
>  > a unique package. openSUSE does *not* define a DistTag or the %dist
>  > variable, so %{?dist} evaluates to nothing. If you're doing rebuilds of your
>  > packages with no source changes from one release of openSUSE to the next, or
>  > rebuilding for new Tumbleweed snapshots, you're going to get collisions all
>  > the time, and builds will just fail because the NVR already exists.
>  >
>  I think ELN won't have this problem (at large scale) because it will inherit
>  sources from Fedora where any new Fedora build has a bumped release for the
>  reason you described. It will resemble more a shadow Koji for the secondary
>  architectures.
>
>  But you are right that funny times can come when an ELN build screws things and
>  ELN people will have to not only untag it but also delete it from the NVR index so
>  that it can be rebuilt again with the same NVR. Fedora people weren't happy if
>  they had to add a dummy release bumps just only because of ELN.
>  
If the goal is to minimize impact on everyone else by ELN work, having
this versioned makes sense because it prevents very annoying
disruptions later on.

>  > This is utter chaos and you *really* don't want that problem
> on your
>  > hands. Having the freedom to do a rebuild cycle for ELN whenever you
>  > want to rebootstrap to a new major without changing sources is a
>  > hugely valuable thing to be able to do.
>  >
>  I think they will just throw it away and start from the scratch. At the end
>  they would like to rebuild all the packages with the new configuration.
>  
I'm pretty sure that nobody is going to let them delete everything
from Koji to redo it. Unless they were spinning this up in a shadow
Koji rather than the main one, which I don't think is the intent here.



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

[Miro Hrončok]

On 06. 04. 20 23:53, Stephen Gallagher wrote:
>  * Clarify that the time limit on PRs is only for determining if the
>  maintainer is responsive. If they reply, the timer is cleared. 
As a side note (probably out of scope of this proposal), I think that if we have 
RHEL packages in Fedora with not very responsive maintainers, the RHEL 
maintainer should really try to get themselves involved in those (or start being 
responsive in case the RHEL maintainers are the Fedora maintainers).

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

[Justin Forbes]

On Mon, Apr 6, 2020 at 5:24 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  On 06. 04. 20 23:53, Stephen Gallagher wrote:
>  > * Clarify that the time limit on PRs is only for determining if the
>  > maintainer is responsive. If they reply, the timer is cleared.
>
>  As a side note (probably out of scope of this proposal), I think that if we have
>  RHEL packages in Fedora with not very responsive maintainers, the RHEL
>  maintainer should really try to get themselves involved in those (or start being
>  responsive in case the RHEL maintainers are the Fedora maintainers).
>  
I think that is a desired side effect of ELN.

[Miro Hrončok]

On 07. 04. 20 0:47, Justin Forbes wrote:
>  On Mon, Apr 6, 2020 at 5:24 PM Miro
> Hrončok<mhroncok(a)redhat.com>  wrote:
> > On 06. 04. 20 23:53, Stephen Gallagher wrote:
> >> * Clarify that the time limit on PRs is only for determining if the
> >> maintainer is responsive. If they reply, the timer is cleared.
> > As a side note (probably out of scope of this proposal), I think that if we have
> > RHEL packages in Fedora with not very responsive maintainers, the RHEL
> > maintainer should really try to get themselves involved in those (or start being
> > responsive in case the RHEL maintainers are the Fedora maintainers).
> >
>  I think that is a desired side effect of ELN. 
I hope it is. What I try to say is that if we "ignore" that packagers are not 
responsive by merging the fix and going away, we are postponing the problem.

Instead (or better: in addition to that), we should nudge the appropriate RHEL 
maintainers to offer help with the Fedora package (and initiate the 
nonresponsive maintainer procedure if that is the only way to participate).

With special emphasis on RHEL packagers who "maintain" the packages in Fedora, 
but are not responding (which happens quite often frankly).

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

[Vít Ondruch]

Dne 06. 04. 20 v 23:53 Stephen Gallagher napsal(a):
>  I've just published a fourth version[1] of the ELN proposal. With
> a
>  lot of input from Miro Hrončok, I think I've finally been able to
>  clarify some of the points that we were getting hung up on.
>
>  Changes in this version of the proposal[2]:
>  
Thank you. I don't have any real concerns ATM. Just a few remarks bellow.


>  * Clarify the relationship with Rawhide 

To my taste, there are quite a lot of remarks such as "If the package
will never build in ELN, then the Rawhide version of it will simply be
present." I think I don't see how it will turn out in practice.

So to say, this is not showstopper and I am fine with that.


>  * Better describe what happens if packages don't build on ELN

Thank you for this paragraph:


~~~

If it would require conditionals to build in ELN and you do not wish to
put them there, but you want to see how changes appear in RHEL, there
will eventually be a way to maintain a fork of your package that will go
into RHEL, but the details on this are still being worked out.

~~~


I think you will soon appreciate it.


>  * Added a section explaining how we will deal with side-tags 

Thank you for addressing this.

However, could you please elaborate what will be the actual trigger to
do rebuild of some package in ELN? It can't be `git push` if you take
side-tags into account. So will it be tagging into 'rawhide' (f33 ATM)?
Will it be mixture? How are you going to determine what is the
appropriate commit hash? You possibly don't know yet ...



Vít

[Stephen Gallagher]

On Tue, Apr 7, 2020 at 3:46 AM Vít Ondruch <vondruch(a)redhat.com&gt; wrote:
...
>  > * Added a section explaining how we will deal with side-tags
>
>
>  Thank you for addressing this.
>
>  However, could you please elaborate what will be the actual trigger to
>  do rebuild of some package in ELN? It can't be `git push` if you take
>  side-tags into account. So will it be tagging into 'rawhide' (f33 ATM)?
>  Will it be mixture? How are you going to determine what is the
>  appropriate commit hash? You possibly don't know yet ... 
I need to investigate how much of it will be net-new work, but we
intend to rely on fedora-messaging notifications to trigger the
rebuilds. Tagging into F33 is probably our best bet; we do actually
have the ability to query Koji for which commit hash was used to run
the build, so we can rely on that. The exact mechanism here is TBD,
but I wanted to make sure the intent of the design was covered in the
Change Proposal.

[Tom Hughes]

On 06/04/2020 22:53, Stephen Gallagher wrote:

>  Changes in this version of the proposal[2]:
>  
>  * Improve our explanation of why we are doing ELN in the first place 
I agree that the proposal is now a lot clearer and I certainly see
how it furthers the first goral of seeing how Fedora trunk comes
together asn an EL build, modulo one concern below.

I don't understand how it helps evaluate something like a new
higher CPU baseline - nobody disputes that packages can be built
to a new baseline which is what this would prove. The argument
is about the effect on consumers of such a baseline and about
what proportion of users/machines would be cut off from further
upgrades and this proposal does nothing to help with that.

>  * Better describe what happens if packages don't build on ELN
>  * Explain our plan for when to use conditionals (this was getting a
>  larger share of the conversation than it warranted because we didn't
>  do a good job of explaining that they should be the exception and not
>  the rule) 
As far as conditionals are concerned I think not defining %fedora
is a key mistake that will both lead to extra conditionals being
needed and also lead to ongoing undetected failures to build
packages in ELN with the latest features of the corresponding
Fedora packages.

Essentially packages will build as if they are on the oldest
possible Fedora rather than the newest possible Fedora because
spec files with a condition on %fedora will typically treat it
as zero when it is not defined.

That will mean that most %fedora conditions will need to be
extended with a %rhel condition and that in many cases new
features may silently not be enabled in ELN builds until that
is manually discovered and the condition is amended which seems
to be the exact opposite of what is required if the goal is to
see how "Fedora Future" builds in an EL environment.

To take just one example hundreds of nodejs packages would build
as if they are on Fedora 18 or earlier because they contain this:

%if 0%{?fedora} >= 19
ExclusiveArch:  %{nodejs_arches} noarch
%else
ExclusiveArch:  %{ix86} x86_64 %{arm} noarch
%endif

Now that is no longer required, and happens to be mostly harmless
because it just means they will hard code the arch list instead of
using the macro, but it's the kind of thing where ELN will wind
up building as if it's an ancient version of Fedora rather than as
if it is rawhide.

>  * Clarify that the time limit on PRs is only for determining if the
>  maintainer is responsive. If they reply, the timer is cleared. 
It might be better to give some idea of what sort of time limit is
envisioned - as it stands the proposal would allow PRs to demand a
response within a day, or an hour or any other ludicrously short
time period. Presumably if it's about looking for inactive maintainers
then something akin to the non-responsive maintainer timelines would
be appropriate?

Tom

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[Miro Hrončok]

On 07. 04. 20 10:09, Tom Hughes via devel wrote:
>  That will mean that most %fedora conditions will need to be
>  extended with a %rhel condition and that in many cases new
>  features may silently not be enabled in ELN builds until that
>  is manually discovered and the condition is amended which seems
>  to be the exact opposite of what is required if the goal is to
>  see how "Fedora Future" builds in an EL environment.
>  
>  To take just one example hundreds of nodejs packages would build
>  as if they are on Fedora 18 or earlier because they contain this:
>  
>  %if 0%{?fedora} >= 19
>  ExclusiveArch:  %{nodejs_arches} noarch
>  %else
>  ExclusiveArch:  %{ix86} x86_64 %{arm} noarch
>  %endif
>  
>  Now that is no longer required, and happens to be mostly harmless
>  because it just means they will hard code the arch list instead of
>  using the macro, but it's the kind of thing where ELN will wind
>  up building as if it's an ancient version of Fedora rather than as
>  if it is rawhide. 
The idea is that if such package indeed is built in ELN, such conditionals 
should be fixed. If we define %fedora in ELN, the problems will only arise in 
RHEL and the conditionals will likely remain unfixed in Fedora.

This particular example might remain unfixed because it "works" as is.

Anyway, when introducing conditionals like this initially, I highly recommend to 
do this instead:

   %if %{defined nodejs_arches}
   ExclusiveArch:  %{nodejs_arches} noarch
   %else
   ExclusiveArch:  %{ix86} x86_64 %{arm} noarch
   %endif

To avoid this kind of bad conditional.

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

[Justin Forbes]

On Tue, Apr 7, 2020 at 3:10 AM Tom Hughes via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  On 06/04/2020 22:53, Stephen Gallagher wrote:
>
>  > Changes in this version of the proposal[2]:
>  >
>  > * Improve our explanation of why we are doing ELN in the first place
>
>  I agree that the proposal is now a lot clearer and I certainly see
>  how it furthers the first goral of seeing how Fedora trunk comes
>  together asn an EL build, modulo one concern below.
>
>  I don't understand how it helps evaluate something like a new
>  higher CPU baseline - nobody disputes that packages can be built
>  to a new baseline which is what this would prove. The argument
>  is about the effect on consumers of such a baseline and about
>  what proportion of users/machines would be cut off from further
>  upgrades and this proposal does nothing to help with that. 
As to what proportion of users/machines would be cut off, we don't
care about the exact number.   It was already established that the
number is an unacceptable amount.  The real question is, how much of a
performance advantage do modern machines get from running things built
for such a baseline.  If there is a significant advantage, then it
becomes worthwhile to explore methods to make relevant packages built
to such a baseline available in standard Fedora.  There have been
various ideas on how to make them available without making them a
required minimum, but all of them involve a non-trivial amount of
work.  It would be a waste of time and energy if the real world
advantage turns out to be minimal.

[Stephen Gallagher]

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

On Mon, Apr 6, 2020 at 5:53 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  I've just published a fourth version[1] of the ELN proposal. With
> a
>  lot of input from Miro Hrončok, I think I've finally been able to
>  clarify some of the points that we were getting hung up on.
>  
Up to this point, we've been a little vague on what "there will
eventually be a way to maintain a fork of your package that will go
into RHEL" actually means. I can finally make this clearer:

- From now until RHEL 9 Alpha ships, work that is intended for
inclusion in RHEL 9 should be contributed to Fedora Rawhide (later,
F34 branch). After Alpha ships, a branch of CentOS Stream will open
that will accept contributions towards RHEL 9 Beta.

I'm pretty excited about this, myself.
> -----BEGIN PGP SIGNATURE-----
>
> iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl6MzJQACgkQRduFpWgo
> bRHp0Av9G5HQD5rdP9JQOtmk2bWfCIXLF0fabZrjPZogIyDVEeEfNQdyledQQnDQ
> RQWpwVP9nYeAjYAOSSAasSnN3jJ71uc08IOYQbHs1hSW+FSM06RNraan4r2rhYOj
> /fWBtwZGABDMLzNrwZqmD6xDtk93yFTo4TWIUWiOwjr02TIIL8A/xiat7TsMHJtS
> 90INry2rQ3qi5OeTTTHQf6bQPHP8FRNTIcgmispObJchHtAPbUKcn6n45b/L5mB6
> 94GVpYf56J3MLoJp2r5TbIdxuJMQSpVwPpk2AbjbWdAQA2SR8LSLU9+HAINiTKQV
> qBmOpHFGTK4e8+VE5W7pqo/sswDminRlCrXd/VQcx6C0jg/AWEQ21JG/DcRvDquP
> n8rMyMf7SKkpj2os3y63MfNXvbm3BHs1BT7znaLbopZG0GxorPsSE/MvwQX9HVka
> nXEGZn7pqXaUhOLWT8+hp0MSQUhkb2j0CVxESsM6AE6u/HGonBR8+T6cDpvP8/EO
> V1QcdQ6M
> =nb+r
> -----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]...

[Vít Ondruch]

Dne 07. 04. 20 v 20:55 Stephen Gallagher napsal(a):
>  On Mon, Apr 6, 2020 at 5:53 PM Stephen Gallagher
> <sgallagh(a)redhat.com&gt;
>  wrote:
>  > I've just published a fourth version[1] of the ELN proposal. With a
>  > lot of input from Miro Hrončok, I think I've finally been able to
>  > clarify some of the points that we were getting hung up on.
>
>  Up to this point, we've been a little vague on what "there will
>  eventually be a way to maintain a fork of your package that will go
>  into RHEL" actually means. I can finally make this clearer:
>
>  - From now until RHEL 9 Alpha ships, work that is intended for
>  inclusion in RHEL 9 should be contributed to Fedora Rawhide (later,
>  F34 branch). 
Then we are back to beginning. If the change is not acceptable for
Rawhide, then there is no place for it.

But honestly, what I really don't understand is that if you are going to
open PR against Rawhide (assuming that you are always going to use PRs,
because you can run CI above them), you have to have (fork and) branch
already. So why don't you formalize this at least?

E.g. "If there is ELN change proposed for Rawhide, then the PR is always
opened from (ELN fork and) ELN branch." And voila, we have the (fork
and) branch! We have a place where the changes can live, waiting for
being (not) accepted. If nothing else, the changes for ELN would be
discoverable, even though you would no used them anywhere unless merged
into Rawhide.


Vít


>  After Alpha ships, a branch of CentOS Stream will open
>  that will accept contributions towards RHEL 9 Beta.
>
>  I'm pretty excited about this, myself.

[Charalampos Stratakis]

----- Original Message -----
>  From: "Stephen Gallagher" <sgallagh(a)redhat.com&gt;
>  To: devel-announce(a)lists.fedoraproject.org
>  Sent: Monday, April 6, 2020 11:53:47 PM
>  Subject: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
>  
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA256
>  
>  I've just published a fourth version[1] of the ELN proposal. With a
>  lot of input from Miro Hrončok, I think I've finally been able to
>  clarify some of the points that we were getting hung up on.
>  
>  Changes in this version of the proposal[2]:
>  
>  * Improve our explanation of why we are doing ELN in the first place
>  * Clarify the relationship with Rawhide
>  * Better describe what happens if packages don't build on ELN
>  * Explain our plan for when to use conditionals (this was getting a
>  larger share of the conversation than it warranted because we didn't
>  do a good job of explaining that they should be the exception and not
>  the rule)
>  * Clarify that the time limit on PRs is only for determining if the
>  maintainer is responsive. If they reply, the timer is cleared.
>  * Fixed the question about upstream features to make it clear that
>  what we meant is that new features should go upstream first, not be
>  implemented as a fork in ELN
>  * Added a section explaining how we will deal with side-tags
>  * Make it clear that we don't want to diverge wherever possible and
>  that any planned divergence should be discussed with the ELN SIG ahead
>  of time
>  * Cleaned up the contingency plan section.
>  
>  I hope that these changes will make our position more clear. Thank you
>  to everyone who has contributed to this discussion. I think the
>  feedback has been very valuable and I sincerely appreciate it.
>  
>  
>  
>  [1] https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
>  [2]
>
> https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_C...
> >  -----BEGIN PGP SIGNATURE-----
> >  
> >  iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl6LpNgACgkQRduFpWgo
> >  bRH4MAwAu1INM0mplL1yQiW2DMS148VubU5DkxRbaE3biZTvw5WzzbpxwpXr+nFp
> >  eZf7IUyn5HCdtCAk1TQ4ga/TuV5VsaEEZ+a9p8PZfs4XTEMGpB7olP0Z8Jq1PWwn
> >  EM6+4BAUWJ4JS7Q1+/CnEkUHA+1ZVeAzeb5bfSlcae2Vgx6evQMB4rEqAXdr16Qk
> >  3Hi082+4SutmBv67cRA/JdRZmvUaHYtS4y5DrWAXOS23k8SHUCT/2O2f7NRPAoG/
> >  f+04nG5JyUePY64pnVtDnsVMwETWiNSSs4V1dbKYe9Fj5H/jbvKIsvo8AWxw4BAq
> >  rXCSIB3wMf08eM2KTaLvk0x+cz2BiSEZEDVdceffVXMwnUZulu/oeYDKdQg9OoHW
> >  IQJbMoASgxRUXH1ZiMy8Q3SgQHvcu/YLmjS+djlVakLunhW7NfQjZB7txMyDi0PY
> >  Hwn32C1kXnaoBJds4zB4QpWiJy5wI82CRL92Zvz0kiRPiO9TMCuj+t5kLZVmVTnI
> >  8ShPIeos
> >  =+lwN
> >  -----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]
>   
I've glanced briefly through the changes, and while I didn't have time to properly
solicit feedback on the info, I would like to say a big thank you for hearing our feedback
and working with that.

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat