[asterisk-dev] tags on the main branches [was: Re: Minor Release Branches]

Fri Dec 22 09:22:09 CST 2017

On Thu, Dec 21, 2017 at 1:44 PM, Corey Farrell <git at cfware.com> wrote:

> George asked that I post some scenarios where this would be useful.
> 1. You are about to create updated asterisk package and want to quickly
> scan the changes to 13 since latest 13.x.0 release to see if anything is a
> 'must patch' for your deployments.  You can use 'tig' to review changes for
> critical fixes until you reach the tag '13.x.0-rc1' (which you can see in
> the list because the tag was merged).
>

I didn't even know about tig.  There's always something to learn about the
git ecosystem. :)

> I know the end result can be accomplished by other means, but not as
> easily.
>
> 2. You've created an automated test to try finding a performance
> regression.  The test runs asterisk under a profiler and stores results.
> Each revision you test needs a new file to store results - 'git describe'
> would provide an excellent filename that is unique per revision.
>
> One thing I'm not sure about is if we should only merge rc1 tags or if we
> should merge all new release tags.  At first all release tags seem
> reasonable, but the order of tags other than rc1 would be off.  rc1 is
> special because it would be merged back to mainline before anything else.
> Even 13.x.0 does not get cut until after other commits are merged to 13, so
> if we merged 13.19.0 to 13, the commits made since 13.19.0-rc1 would appear
> out of order (before 13.19.0).  The difference between rc1 and final
> release is always small, but the number of new commits to mainline between
> that time can be quite large.
>
So we would merge rc1's back to mainline but how about the point releases?
13.19.0-rc1
13.19.1  ??
13.19.2  ??

13.18-cert1-rc1
13.18-cert2 ??
13.18-cert3 ??

> On 12/21/2017 10:45 AM, Corey Farrell wrote:
>
> I just read `git help merge` again and I think the solution is 'git
> checkout 13 && git merge --strategy ours 13.19.0-rc1'.  This would
> effectively tell git that '13' already contains 13.19.0-rc1, but without
> actually trying to pull any changes to 13.  This merge would be the final
> step of mkrelease.py.
>
> No changes will be needed to our handling of '.lastclean', please ignore
> those comments as I was wrong.
>
> On 12/21/2017 08:19 AM, George Joseph wrote:
>
>
>
> On Wed, Dec 20, 2017 at 3:14 PM, Corey Farrell <git at cfware.com> wrote:
>
>> One thing that might improve this is if releases were merged back to the
>> major branch.  Currently the commit "Update for 13.19.0-rc1" is on the
>> 13.19 branch and tagged as 13.19.0-rc1.  I believe that if we added 'git
>> checkout 13 && git merge 13.19.0-rc1' we would get better information from
>> 'git describe 13' and tags would appear in 'git log 13 --oneline'.  This
>> would continue working even after we delete the minor branches.
>>
> Sounds reasonable.
>
>
>
>> As a test I just ran 'git merge 13.18.4' from the current 13 branch.  The
>> merge did have 2 conflicts but that's because 13.18 was branched so long
>> ago and a couple files that were modified in minor releases have since been
>> modified again or deleted.  Then I ran 'git describe 13', it said
>> '13.18.4-404-gd5d67bb1f4'.  This tells us that my local branch had about
>> 404 commits (including merges) that are not part of 13.18.0-rc1 (the point
>> where 13.18 diverged from 13 because 13.18.3 was not merged back).  Merging
>> each tag as soon as it's created would make the results more accurate. and
>> (almost always) eliminate merge conflicts.
>>
> "almost always" will be an issue since it's the scripts that do the work.
> It's kinda frustrating already when you're trying to get releases out the
> door and something goes wrong with the script.  What conditions do you
> think might still cause merge conflicts?
>
>
>> The only wrinkle in this plan is that the '.lastclean' file is created on
>> the releases but it's listed in .gitignore.  I think we might be able to
>> just get rid of the .lastclean and .cleancount files.  This Makefile hack
>> predates the use of SVN and I don't think it's necessary.  One thing it
>> does do is try to enable the astdb2sqlite3 utility, but Berkely DB was last
>> used in Asterisk 1.8.  The default is for that utility to be enabled,
>> that's enough.  In addition the mkrelease script actually copies
>> .cleancount to .lastclean, I think that means it's disabled for releases.
>>
> These kind of things we can alter to suite our needs so there shouldn't be
> an issue.
>
>
>>
>> On 12/20/2017 12:58 PM, George Joseph wrote:
>>
>>
>>
>> On Wed, Dec 20, 2017 at 8:14 AM, Tzafrir Cohen <tzafrir.cohen at xorcom.com>
>> wrote:
>>
>>> On Wed, Dec 20, 2017 at 07:50:03AM -0700, George Joseph wrote:
>>> > On Wed, Dec 20, 2017 at 2:44 AM, Tzafrir Cohen <
>>> tzafrir.cohen at xorcom.com>
>>> > wrote:
>>> >
>>> > > Off-topic:
>>> > >
>>> > > On Tue, Dec 19, 2017 at 01:50:03PM -0700, George Joseph wrote:
>>> > >
>>> > > > Thankfully we tag EVERYTHING! :)
>>> > >
>>> > > asterisk(13)$ git describe
>>> > > 13.15.0-rc1-908-ge31e3b581b
>>> > >
>>> > > asterisk(14)$ git describe
>>> > > fatal: No tags can describe 'fb18797ae09a685ec71101499fb1c
>>> 1c606b16397'.
>>> > > Try --always, or create some tags.
>>> > >
>>> > > asterisk(15)$ git describe
>>> > > fatal: No tags can describe 'd312068ee93ff8ce97b464f3c2ff3
>>> 304e15cb3fe'.
>>> > > Try --always, or create some tags.
>>> > >
>>> > >
>>> > > I wasted half an hour yesterday trying to find out why a build sis
>>> not
>>> > > switch from master to 13, only to realize that the name of the git
>>> > > branch in the version string is always "master".
>>> > >
>>> > > We tag everything. But only well after it was branched from the main
>>> > >
>>> > branch.
>>> > >
>>> >
>>> > I'm not following you.
>>> >
>>> > We tag every release...
>>> >
>>> > $ git checkout 13.18.4
>>> > HEAD is now at f4644317b7... Update for 13.18.4
>>> > $ git describe
>>> > 13.18.4
>>>
>>>
>>> > $ git checkout 13.18
>>> > Switched to branch '13.18'
>>> > Your branch is up-to-date with 'gerrit/13.18'.
>>> > $ git describe
>>> > 13.18.4
>>>
>>>
>>> > $
>>> >
>>> > We have to create the minor release branch (13.18) and do the work
>>> there so
>>> > that patch releases (13.18.4) are based on the minor release branch,
>>> not
>>> > the major branch.
>>>
>>> Those branches are likewise short-lived branches (at least with respect
>>> to the number of commits). Real work is done on master, 13, 15 and such.
>>> But when I'm on such a branch, I can't ask git on which branch I am (not
>>> to mention: at which stage in it).
>>>
>>
>>  I _think_ I understand now.
>>
>>>
>>> For instance: maybe whenever you tag a new release branch (e.g. 13.18),
>>> tag the split point as something like "13.18.base" or "base.13.18"?
>>>
>>
>> Well, that's easy enough.  Toss us an issue for it.
>>
>>
>>>
>>> But maybe it's just me and branches 13 and 15 are not widely used (for
>>> master it is irrelevant anyway).
>>>
>>> --
>>>                Tzafrir Cohen
>>> +972-50-7952406           mailto:tzafrir.cohen at xorcom.com
>>> http://www.xorcom.com
>>>
>>> --
>>> _____________________________________________________________________
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> asterisk-dev mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>>>
>>
>>
>>
>> --
>> George Joseph
>> Digium, Inc. | Software Developer
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
>> Check us out at: www.digium.com & www.asterisk.org
>>
>>
>>
>>
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>
>
>
> --
> George Joseph
> Digium, Inc. | Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> Check us out at: www.digium.com & www.asterisk.org
>
>
>
>
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>

-- 
George Joseph
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20171222/dd4672bc/attachment-0001.html>