On Fri, Dec 22, 2017 at 9:50 AM, Corey Farrell <g...@cfware.com> wrote:
> On 12/22/2017 10:22 AM, George Joseph wrote: > > > > On Thu, Dec 21, 2017 at 1:44 PM, Corey Farrell <g...@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. > Sorry, I'm being thick... So if it's only the rc1's then why won't an annotated tag do what you want without having to alter the mainline commit history with a merge? > > 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. > we manually cut the 16 branch from master before anything then the release process creates 16.0 when we release beta1. > > 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 <g...@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.co...@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.co...@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.co...@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 > > > > > > -- > _____________________________________________________________________ > -- 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