On Thu, Dec 21, 2017 at 1:44 PM, Corey Farrell <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 < >>> [email protected]> >>> > 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:[email protected] >>> 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
