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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Okay then. :)


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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux