[asterisk-dev] tags on the main branches [was: Re: Minor Release Branches]
Corey Farrell
git at cfware.com
Fri Dec 22 10:50:14 CST 2017
On 12/22/2017 10:22 AM, George Joseph wrote:
>
>
> On Thu, Dec 21, 2017 at 1:44 PM, Corey Farrell <git at cfware.com
> <mailto: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 ??
Just to be clear certified branches would be untouched by this
proposal. Look at 'git log certified/13.13-cert9' - you will see the
previous tagged releases in the certified/13.13 release series.
I think we should not do anything different with the point releases
(including 13.19.0) because of the commit order. Think about when
13.18.4 were released. If we merged it to 13 it would be in the wrong
place on 'git log 13'. Easily 200 non-merge commits would appear after
the 13.18.4 tag in the 13 branch, when in fact they are not part of the
13.18.4 tag. My hope is that we can provide additional information, but
only if the information is accurate.
One last detail I don't know exactly how we deal with new major releases
(ie 16.0.0). If I remember correctly we will release 16.0.0-beta1, but
I don't remember if that is the start of the 16.0 branch or if 16.0
starts with rc1. However it works my current proposal would be to merge
the first commit of 16.0 back to 16.
Tzafrir I haven't heard from you since I joined your new thread. If we
were to merge the rc1's back to mainline so that mainline knew about the
"split point", would this satisfy your request? Also was your intent to
say "we should do this first before deleting minor branches"? Do you
object if we proceed with removal of minor branches or does your request
need to be completed first?
>
>
> 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
>>> <mailto: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
>>>> <mailto: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
>>>> <mailto: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
>>>> 'fb18797ae09a685ec71101499fb1c1c606b16397'.
>>>> > > Try --always, or create some tags.
>>>> > >
>>>> > > asterisk(15)$ git describe
>>>> > > fatal: No tags can describe
>>>> 'd312068ee93ff8ce97b464f3c2ff3304e15cb3fe'.
>>>> > > 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
>>>> <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
>>>> <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 <http://www.digium.com/> &
>>>> www.asterisk.org <http://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
>>> <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 <http://www.digium.com/> &
>>> www.asterisk.org <http://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
> <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 <http://www.digium.com/> &
> www.asterisk.org <http://www.asterisk.org/>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20171222/6c8df5f5/attachment-0001.html>
More information about the asterisk-dev
mailing list