On Tue, Apr 7, 2020 at 7:55 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > On Tue, Apr 7, 2020 at 1:50 PM Aleksandra Fedorova <alpha@xxxxxxxxxxxx> wrote: > > > > Hi, > > > > On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok <mhroncok@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx/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 to actively experiment with the buildroot setup. So it makes sense to track it through versioning. > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > _______________________________________________ > devel mailing list -- devel@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 -- Aleksandra Fedorova bookwar _______________________________________________ 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
