On Tue, Mar 02, 2021 at 09:30:41PM +0100, Fabio Valentini wrote:
> On Tue, Feb 16, 2021 at 8:20 PM Pierre-Yves Chibon <pin...@pingoured.fr> 
> wrote:
> >
> > On Tue, Feb 16, 2021 at 03:38:35PM +0100, Fabio Valentini wrote:
> > > On Tue, Feb 16, 2021 at 3:01 PM Miro Hrončok <mhron...@redhat.com> wrote:
> > > >
> > > > On 16. 02. 21 14:48, Fabio Valentini wrote:
> > > > >      if version_at(commit) != last_version:
> > > > >          return 0
> > > >
> > > > Should this be "return 1"?
> > >
> > > No, 0 is correct. If the version does not match, this is the last
> > > commit *before* a version update.
> > > The "max(parents) + 1" then sets the Release to 1 for the commit that
> > > actually changed the version :)
> > >
> > > > To prevent accidental divergence between the git history and the build 
> > > > system.
> > > > That's why this information is only used in the koji plugin, locally 
> > > > (ie: via
> > > > the rpmautospec CLI) it only relies on the git tags.
> > >
> > > So ... you want to *prevent* divergence by *introducing* divergence? I
> > > do not follow ...
> >
> > The build information is used to check if all the builds made in koji 
> > exists as
> > tags. If they don't, then they are added, thus resolving the divergence.
> > If they do, git tags are used, just like they are used locally.
> 
> There's another issue that I see with using both git tags and koji
> build history:
> How do users get those tags into their local repository clones, if
> they are created by koji after successful builds?

The first time it can be done via the rpmautospect CLI command.

> Will we need to "git pull" after every successful koji build so we get
> consistent results between local checkout and infra build?

After that, git pull/fetch is indeed the easiest method.

> Side note: This amended algorithm should always produce incrementing
> release numbers, even across branches:
> 
> def release_num(commit, last_version) -> int:
>     if version_at(commit) != last_version:
>         return 0
>     else:
>         distance = max(release_num(parent, last_version) for parent of 
> commit))
>         if is_merge_commit(commit):
>             return distance
>         else:
>             return distance + 1
> 
> That should solve both the upgrade path issue and the data source
> problem. No need to look at either git tags or koji build history :)

The devil is in the details: pre-release, snapinfo, minorbump aren't really
covered by distance being just an integer bumped.

I know we considered the "number of commits since the last version bump" when we
looked into this. I honestly do not remember precisely why we didn't go with it.

Maybe Nils or Adam remember it?


Pierre
_______________________________________________
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to