On Tue, Apr 7, 2020, at 2:42 PM, Josh Boyer wrote: > On Tue, Apr 7, 2020 at 2:27 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > > > On Tue, Apr 7, 2020 at 2:16 PM Neal Gompa <ngompa13@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
