Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
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: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
Dne 07. 04. 20 v 20:55 Stephen Gallagher napsal(a): > On Mon, Apr 6, 2020 at 5:53 PM Stephen Gallagher > 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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
- Original Message - > From: "Stephen Gallagher" > To: devel-annou...@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_Compose=revision=570854=570256 > -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-annou...@lists.fedoraproject.org > To unsubscribe send an email to devel-announce-le...@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-annou...@lists.fedoraproject.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org > 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Apr 6, 2020 at 5:53 PM Stephen Gallagher 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-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@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-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Apr 6, 2020 at 5:53 PM Stephen Gallagher 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@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 2:49 PM James Cassell 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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020, at 2:42 PM, Josh Boyer wrote: > On Tue, Apr 7, 2020 at 2:27 PM Stephen Gallagher wrote: > > > > On Tue, Apr 7, 2020 at 2:16 PM Neal Gompa 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 2:27 PM Stephen Gallagher wrote: > > On Tue, Apr 7, 2020 at 2:16 PM Neal Gompa 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 2:27 PM Stephen Gallagher wrote: > > On Tue, Apr 7, 2020 at 2:16 PM Neal Gompa 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! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 2:16 PM Neal Gompa 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.) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 2:11 PM Aleksandra Fedorova wrote:
>
> On Tue, Apr 7, 2020 at 7:55 PM Neal Gompa wrote:
> >
> > On Tue, Apr 7, 2020 at 1:50 PM Aleksandra Fedorova
> > wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok 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/devel@lists.fedoraproject.org/message/OQ7BW5RFQDJYLPTB6G5XBZSIYDXKK5AW/
> > > > >
> > > > > 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
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 7:55 PM Neal Gompa wrote:
>
> On Tue, Apr 7, 2020 at 1:50 PM Aleksandra Fedorova wrote:
> >
> > Hi,
> >
> > On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok 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/devel@lists.fedoraproject.org/message/OQ7BW5RFQDJYLPTB6G5XBZSIYDXKK5AW/
> > > >
> > > > 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
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 2:02 PM Stephen Gallagher wrote:
>
> On Tue, Apr 7, 2020 at 1:56 PM Neal Gompa 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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 1:56 PM Neal Gompa 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 1:50 PM Aleksandra Fedorova wrote:
>
> Hi,
>
> On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok 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/devel@lists.fedoraproject.org/message/OQ7BW5RFQDJYLPTB6G5XBZSIYDXKK5AW/
> > >
> > > 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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
Hi,
On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok 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/devel@lists.fedoraproject.org/message/OQ7BW5RFQDJYLPTB6G5XBZSIYDXKK5AW/
> >
> > 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: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
--
--
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 3:10 AM Tom Hughes via devel 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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 7:33 AM Petr Pisar 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
> > wrote:
> > > On Mon, Apr 6, 2020 at 6:09 PM Neal Gompa 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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Tue, Apr 7, 2020 at 3:46 AM Vít Ondruch 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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Mon, Apr 06, 2020 at 06:48:17PM -0400, Neal Gompa wrote:
> On Mon, Apr 6, 2020 at 6:22 PM Stephen Gallagher wrote:
> > On Mon, Apr 6, 2020 at 6:09 PM Neal Gompa 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
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
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/devel@lists.fedoraproject.org/message/OQ7BW5RFQDJYLPTB6G5XBZSIYDXKK5AW/
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: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
Hi, Neal,
On Tue, Apr 7, 2020 at 12:49 AM Neal Gompa wrote:
>
> On Mon, Apr 6, 2020 at 6:22 PM Stephen Gallagher wrote:
> >
> >
> >
> > On Mon, Apr 6, 2020 at 6:09 PM Neal Gompa 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/devel@lists.fedoraproject.org/message/OQ7BW5RFQDJYLPTB6G5XBZSIYDXKK5AW/
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
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: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
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 (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On 07. 04. 20 0:47, Justin Forbes wrote: On Mon, Apr 6, 2020 at 5:24 PM Miro Hrončok 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: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Mon, Apr 6, 2020 at 6:22 PM Stephen Gallagher wrote:
>
>
>
> On Mon, Apr 6, 2020 at 6:09 PM Neal Gompa 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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Mon, Apr 6, 2020 at 5:24 PM Miro Hrončok 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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
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: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Mon, Apr 6, 2020 at 6:09 PM Neal Gompa wrote: > On Mon, Apr 6, 2020 at 5:56 PM Stephen Gallagher > 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
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: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
On Mon, Apr 6, 2020 at 5:56 PM Stephen Gallagher 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! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
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_Compose=revision=570854=570256 -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@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@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@lists.fedoraproject.org
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_Compose=revision=570854=570256 -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-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@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-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
