Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of mmocny@google.com designates
 209.85.210.42 as permitted sender)
MIME-Version: 1.0
Sender: mmocny@google.com
In-Reply-To: 
 <CABiQX1VA9CBQjqob+O8sx3CJYwrorNwV+tJdoRx+-1BhwgBr6A@mail.gmail.com>
References: 
 <CAOBL_k71Ye32BEgG=iiaHo1WEduWTakxBd+Be3-WgqrwF66yLQ@mail.gmail.com>
	<CD09CADF.14C5A%fil@adobe.com>
	<CAESi+48WBh__-QfsDjqpwkoQV+RmOgCkrsMmybDUftmibDd4NA@mail.gmail.com>
	<CAEeF2Teu29Ygeaa53vUzMZYWYRg+FVb-=w31Yn8cq8iRMeztEA@mail.gmail.com>
	<CAEeF2TdofAWDU=b7aSmhNtF7CeW_Hi0+W9bA53mwRArdDHdqoQ@mail.gmail.com>
	<CAESi+4-vbcB+TpGtbgx5enCLZJRAdbb1S-_vvjanes-BrP-Zyg@mail.gmail.com>
	<CAESi+4_gBZesGp3M-c8raRt0KeFMjLt-GdgESXpw9ZuM=BzY5g@mail.gmail.com>
	<CABiQX1VA9CBQjqob+O8sx3CJYwrorNwV+tJdoRx+-1BhwgBr6A@mail.gmail.com>
Date: Wed, 2 Jan 2013 23:05:12 -0500
Message-ID: 
 <CAEeF2Tf6MH=1y0egNECWtbyJ8w_gLY-XcO=w8av46baySaFDWA@mail.gmail.com>
Subject: Re: too long to package a release?
From: Michal Mocny <mmocny@chromium.org>
To: dev@cordova.apache.org
Content-Type: multipart/alternative; boundary=047d7b10cbcb3249fd04d25a78c1

--047d7b10cbcb3249fd04d25a78c1
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jan 2, 2013 at 7:27 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> From my understanding of git, there's nothing special about the master
> branch, except that it's what gets checked out when someone doesn't
> explicitly say which branch they want.
>
> Joe pointed out that sometimes random people check out the code and expect
> it to be stable.
> Gord pointed out that people tend to submit pull requests assuming that
> master == dev branch.
>
> I think choosing between these two data points, I'd lean towards having
> people submit more useful pull requests.
>
Well put, agreed.


>
> I don't think either option affects how you'd go about doing a point
> release. You would:
> 1. Check out the relevant release tag (e.g. 2.3.0)
> 2. Give the branch a name (e.g. branch_2.3.1)
>
I'm not sure why you would name the branch after checkout?  Wouldn't you
name it by tagging after doing the merges in step 3?


> 3. Merge in all of the changes that you want to put in the point release
> (ideally, these would already be committed in the dev branch, be it "next"
> or "master").
> 4. Tag the release.
>
>
> On Wed, Jan 2, 2013 at 5:11 PM, Gord Tanner <gtanner@gmail.com> wrote:
>
> > Also a problem we have encountered with using a 'next' branch for active
> > development is from third party commits.
> >
> > Every single 3rd party pull request is going to come into master.
> >
> > You can ether:
> > 1. tell them to redo it on next
> > 2. rebase it into next for them and let them know for next time.
> >
> > The cost of option 2 gets more the longer it takes to release.  A 3rd
> party
> > pull request coming in could be based on code that is 2+ months old.
> >
> > This isn't a vote against a development branch, but a small annoyance we
> > have run into.
> >
> >
> > On Wed, Jan 2, 2013 at 5:08 PM, Gord Tanner <gtanner@gmail.com> wrote:
> >
> > > A hot fix is usually branched off of master, tested, merged and
> released.
> > >
> > > We then rebase / merge the hotfix up into next.
> > >
> > >
> > > On Wed, Jan 2, 2013 at 4:51 PM, Michal Mocny <mmocny@chromium.org>
> > wrote:
> > >
> > >> Also: while I personally prefer master to be the dev channel, I will
> say
> > >> that I do like Gord's suggestion of how its done in ripple in that the
> > >> name
> > >> of the dev branch is 'next' and not '2.3.0' so that your dev setup
> > doesn't
> > >> need to change every month.
> > >>
> > >> Gord: how do you deal with bugfixes/point releases?  Do you fix in
> > feature
> > >> branch, merge into next, and then cherry-pick/merge just that fix into
> > >> master before doing a major release?  Or, do you just offer bugfixes
> via
> > >> 'next'?
> > >>
> > >>
> > >> On Wed, Jan 2, 2013 at 4:45 PM, Michal Mocny <mmocny@chromium.org>
> > wrote:
> > >>
> > >> > I don't have much weight here, but personally I feel that this seems
> > >> > backwards.
> > >> >
> > >> > With this proposal (if I understand it), when you do a fresh
> checkout
> > of
> > >> > the codebase, instead of sitting on the bleeding edge, you would be
> > >> sitting
> > >> > at a "stable" release which is conceptually read-only for most
> > >> contributors
> > >> > (writes happen in the form of batch "releases" which itself would
> just
> > >> be
> > >> > some git-fu to rebase master).
> > >> >
> > >> > I am happy enough to have features be worked on in branches etc, I
> > just
> > >> > think that it should be flipped and the stable release be the branch
> > and
> > >> > dev to be on master.
> > >> >
> > >> >
> > >> > As a separate issue, I would suggest not using branches to "name"
> > point
> > >> > releases, but just tag them.  If you have a 2.3.0 release, and you
> > need
> > >> to
> > >> > fix a bug in 2.3.1, those should not become two logically separate
> > code
> > >> > branches with independent dev, but rather they are a logically
> single
> > >> > timeline with many names for each historically significant commit,
> > >> right?
> > >> >  Thats what tags are for (
> > http://git-scm.com/book/en/Git-Basics-Tagging
> > >> ).
> > >> >
> > >> > -Michal
> > >> >
> > >> >
> > >> > On Wed, Jan 2, 2013 at 3:05 PM, Gord Tanner <gtanner@gmail.com>
> > wrote:
> > >> >
> > >> >> This is what we have done in ripple (and webworks)
> > >> >>
> > >> >> master - always stable current shipping code
> > >> >> next - always 'stable' next release. Expectation that code has been
> > >> tested
> > >> >> / run before merged into this branch.
> > >> >> feature branches - branched off of next and merged into next when
> > >> stable /
> > >> >> done. Not expected to be stable or runnable until merge time.
> > >> >>
> > >> >>
> > >> >>
> > >> >> On Wed, Jan 2, 2013 at 2:32 PM, Filip Maj <fil@adobe.com> wrote:
> > >> >>
> > >> >> > Am I correct when I say that, with this approach, master becomes
> a
> > >> >> series
> > >> >> > of merge commits coming from dev, then ?
> > >> >> >
> > >> >> > A couple questions to follow up:
> > >> >> >
> > >> >> > - "features get forked from stable" - forked from master, yes?
> > >> >> > - "features, when ready, tested against dev branch" - what does
> > this
> > >> >> mean?
> > >> >> > Does this mean, you would merge feature branch into dev branch
> > >> (locally)
> > >> >> > then run tests to make sure things work?
> > >> >> >
> > >> >> > On 1/2/13 11:19 AM, "Joe Bowser" <bowserj@gmail.com> wrote:
> > >> >> >
> > >> >> > >OK, Let's rethink this:
> > >> >> > >
> > >> >> > >After talking with Brian on the 21st, I think we agree on this:
> > >> >> > >
> > >> >> > > * Master remains stable and sits at the most recent released
> code
> > >> >> > >(i.e. 2.3.0 once we get 2.3.0 done) (Stable Channel)
> > >> >> > > * Dev happens on branches for the releases (i.e. 2.4.0) (Dev
> > >> Channel)
> > >> >> > > * In the case of a point release, dev happens in the branch of
> > the
> > >> >> > >major release (i.e. 2.3.1 would happen in the 2.3.0 branch, not
> > >> >> > >master) (Testing Channel)
> > >> >> > > * Features get forked on stable then once the feature is ready,
> > >> >> > >tested against the dev branch.  If they work with stable, they
> > >> SHOULD
> > >> >> > >work with 2.4.0.  If they don't, the tickets get added to 2.4.0
> to
> > >> >> > >make it work with that release.  That way things are more
> > >> predictable
> > >> >> > >as far as new features are concerned. (You will burn your face
> > >> >> > >channel).
> > >> >> > >
> > >> >> > >Does that make sense? Working on master for things causes us
> pain
> > >> and
> > >> >> > >we should use git conventions to make it simpler for people who
> > >> expect
> > >> >> > >our master to work all the time.  I don't think this will speed
> up
> > >> the
> > >> >> > >release as much as automating tagging of RCs so that when the JS
> > is
> > >> >> > >tagged, everything else is tagged.  The week it takes to tag an
> RC
> > >> is
> > >> >> > >way too long.
> > >> >> > >
> > >> >> > >
> > >> >> > >On Wed, Jan 2, 2013 at 11:08 AM, Filip Maj <fil@adobe.com>
> wrote:
> > >> >> > >> Bumping this thread. I'd like Joe to clarify as well.
> > >> >> > >>
> > >> >> > >> On 12/20/12 12:26 PM, "Brian LeRoux" <b@brian.io> wrote:
> > >> >> > >>
> > >> >> > >>>Ok, I want to understand this, let me take a stab.
> > >> >> > >>>
> > >> >> > >>>You describe three long-lived branches like this:
> > >> >> > >>>
> > >> >> > >>>- Master: This is stable and frozen on the last tagged
> release.
> > >> >> > >>>- Dev: the next release to be tagged. Feature branches merged
> > from
> > >> >> > >>>master when confident.
> > >> >> > >>>- Unstable: the current working branch for a particular tag.
> > >> Feature
> > >> >> > >>>branches merged as needed for collaboration.
> > >> >> > >>>
> > >> >> > >>>Everyone works from local feature branch rebasing and
> committing
> > >> to
> > >> >> > >>>master. When that feature branch is considered good enough, it
> > is
> > >> >> > >>>merged into dev, and work continues. Whatever date we happen
> to
> > >> pick
> > >> >> > >>>for a release that is what dev becomes, we tag, and move that
> > sha
> > >> to
> > >> >> > >>>stable if its not an RC.
> > >> >> > >>>
> > >> >> > >>>?
> > >> >> > >>>
> > >> >> > >>>
> > >> >> > >>>
> > >> >> > >>>
> > >> >> > >>>On Thu, Dec 20, 2012 at 10:52 AM, Joe Bowser <
> bowserj@gmail.com
> > >
> > >> >> wrote:
> > >> >> > >>>> I'm OK with this, but I think your example is off:
> > >> >> > >>>>
> > >> >> > >>>> Where n is the current released piece of the software:
> > >> >> > >>>>
> > >> >> > >>>> n.x.x = Stable
> > >> >> > >>>> n+1.x.x = Dev
> > >> >> > >>>> master = Unstable, can have things merged in from feature
> > >> branches
> > >> >> > >>>>
> > >> >> > >>>> This fully uncouples features from release planning, which
> is
> > >> good
> > >> >> > >>>> because it means the release will land in the version when
> > it's
> > >> >> ready,
> > >> >> > >>>> and not for any other reason.  I also propose that we keep
> > using
> > >> >> the
> > >> >> > >>>> same RC tags and that for a final release we tag it
> > x.x.xFinal.
> > >>  We
> > >> >> > >>>> still need to tag an RC and re-tag it.
> > >> >> > >>>>
> > >> >> > >>>> Release Process:
> > >> >> > >>>> 1. Tag the dev tree
> > >> >> > >>>> 2. merge the dev tree back into master
> > >> >> > >>>> 3. Create 2.5.0 branch
> > >> >> > >>>> 4. File issues from 2.5.0 in JIRA
> > >> >> > >>>>
> > >> >> > >>>> I also propose that we automate the tagging.  If an RC is
> > >> broken,
> > >> >> we
> > >> >> > >>>> just cut another RC.  A lot of our retagging is done to get
> > >> around
> > >> >> the
> > >> >> > >>>> pain of having to do another RC.  The biggest part of the
> > delay
> > >> is
> > >> >> > >>>> waiting for every single platform maintainer to tag their
> > >> platform
> > >> >> > >>>> after the JS was tagged.  For example, I tagged rc2 for the
> JS
> > >> and
> > >> >> for
> > >> >> > >>>> Android on Monday last week from my hotel room, and the
> > release
> > >> >> wasn't
> > >> >> > >>>> fully tagged until this week.  I'm fine with RCs going up to
> > 10
> > >> as
> > >> >> > >>>> long as we can release early, release often and release when
> > we
> > >> >> want
> > >> >> > >>>> to and not run out of time and have to delay.
> > >> >> > >>>>
> > >> >> > >>>> On Thu, Dec 20, 2012 at 10:33 AM, Brian LeRoux <b@brian.io>
> > >> wrote:
> > >> >> > >>>>> Truth. Though lets not get hung up on the past and just
> focus
> > >> on
> > >> >> the
> > >> >> > >>>>> present. We've done a really good job getting where we are.
> > >> >> > >>>>>
> > >> >> > >>>>> So, Joe, are you saying you like the idea of three long
> lived
> > >> >> > >>>>>branches
> > >> >> > >>>>> and merges happen from local feature branches?
> > >> >> > >>>>>
> > >> >> > >>>>>
> > >> >> > >>>>> On Thu, Dec 20, 2012 at 10:22 AM, Joe Bowser <
> > >> bowserj@gmail.com>
> > >> >> > >>>>>wrote:
> > >> >> > >>>>>> We are totally doing something wrong with the way that we
> do
> > >> >> > >>>>>>releases.
> > >> >> > >>>>>>  I personally think that we're not using git right, and
> > here's
> > >> >> why:
> > >> >> > >>>>>>
> > >> >> > >>>>>> Currently, when we do a release, we tag the RC, and we
> test
> > >> the
> > >> >> RC.
> > >> >> > >>>>>> There's nothing preventing us from putting things after
> that
> > >> tag
> > >> >> and
> > >> >> > >>>>>> if we don't want to those things in the release branching
> > off
> > >> >> that
> > >> >> > >>>>>> tag.  We've done it before and other than the problem with
> > >> CoHo,
> > >> >> it
> > >> >> > >>>>>> worked really well.  I propose that instead of tagging the
> > >> >> release,
> > >> >> > >>>>>>we
> > >> >> > >>>>>> branch when we want to do a release, and we do all the bug
> > >> fixes
> > >> >> on
> > >> >> > >>>>>> that branch.  Once that branch is ready to roll, we merge
> it
> > >> back
> > >> >> > >>>>>>into
> > >> >> > >>>>>> master.  In fact, nobody should be working on master
> except
> > >> to do
> > >> >> > >>>>>> merges.  The way we're doing this now feels dirty and
> wrong.
> > >> >> > >>>>>>
> > >> >> > >>>>>> I honestly feel that this is a much faster way of working,
> > and
> > >> >> that
> > >> >> > >>>>>> we're missing the point if we have to tell everyone to
> jump
> > >> out
> > >> >> of
> > >> >> > >>>>>>the
> > >> >> > >>>>>> pool every time we do an RC.  I know that we could be
> > working
> > >> on
> > >> >> our
> > >> >> > >>>>>> branches, but that work is almost entirely invisible to
> the
> > >> rest
> > >> >> of
> > >> >> > >>>>>> the project until it's time to merge it back in, which
> takes
> > >> >> > >>>>>>forever.
> > >> >> > >>>>>>
> > >> >> > >>>>>>
> > >> >> > >>>>>> On Thu, Dec 20, 2012 at 10:07 AM, Michal Mocny <
> > >> >> mmocny@chromium.org
> > >> >> > >
> > >> >> > >>>>>>wrote:
> > >> >> > >>>>>>> So there is something to be said about having devs shift
> > >> focus
> > >> >> from
> > >> >> > >>>>>>>dev to
> > >> >> > >>>>>>> testing during an RC.  However, as the team grows, not
> all
> > >> of us
> > >> >> > >>>>>>>are
> > >> >> > >>>>>>>really
> > >> >> > >>>>>>> being responsible for cutting releases.  Maybe that means
> > we
> > >> >> need
> > >> >> > >>>>>>>to
> > >> >> > >>>>>>>train
> > >> >> > >>>>>>> the entire team to change current behavior, but that
> > doesn't
> > >> >> feel
> > >> >> > >>>>>>> necessary/scalable.
> > >> >> > >>>>>>>
> > >> >> > >>>>>>> With growing external contributions, I would have to say
> > >> that a
> > >> >> > >>>>>>>code
> > >> >> > >>>>>>>freeze
> > >> >> > >>>>>>> on trunk doesn't seem to make as much sense.
> > >> >> > >>>>>>>
> > >> >> > >>>>>>> -Michal
> > >> >> > >>>>>>>
> > >> >> > >>>>>>>
> > >> >> > >>>>>>> On Thu, Dec 20, 2012 at 9:47 AM, Andrew Grieve
> > >> >> > >>>>>>><agrieve@chromium.org> wrote:
> > >> >> > >>>>>>>
> > >> >> > >>>>>>>> I definitely think we'd get more done if we didn't have
> > >> such a
> > >> >> > >>>>>>>>long
> > >> >> > >>>>>>>> code-freeze. I'm not sure this is the same as what you
> > were
> > >> >> > >>>>>>>>suggesting, but
> > >> >> > >>>>>>>> have a script/tool to branch all of the platforms into
> an
> > rc
> > >> >> > >>>>>>>>branch. Then,
> > >> >> > >>>>>>>> each platform can fix themselves up a bit and tag their
> > RC.
> > >> >> > >>>>>>>>Meanwhile, dev
> > >> >> > >>>>>>>> can continue to happen on edge.
> > >> >> > >>>>>>>>
> > >> >> > >>>>>>>> My main concern with our current approach is just that
> the
> > >> >> > >>>>>>>>code-freeze time
> > >> >> > >>>>>>>> is super long.
> > >> >> > >>>>>>>>
> > >> >> > >>>>>>>>
> > >> >> > >>>>>>>> On Wed, Dec 19, 2012 at 3:36 PM, Marcel Kinard
> > >> >> > >>>>>>>><cmarcelk@gmail.com>
> > >> >> > >>>>>>>>wrote:
> > >> >> > >>>>>>>>
> > >> >> > >>>>>>>> > One of the things that strikes me here is the
> difference
> > >> >> between
> > >> >> > >>>>>>>>calendar
> > >> >> > >>>>>>>> > time and effort time. (This assumes folks already
> > >> concurred
> > >> >> that
> > >> >> > >>>>>>>>the rc
> > >> >> > >>>>>>>> is
> > >> >> > >>>>>>>> > ready to release.) Based on my reading of
> > >> >> > >>>>>>>>http://wiki.apache.org/**
> > >> >> > >>>>>>>> > cordova/CuttingReleases
> > >> >> > >>>>>>>><http://wiki.apache.org/cordova/CuttingReleases>there
> > >> >> > >>>>>>>> isn't a lot of effort time involved to cut a release. It
> > >> seems
> > >> >> > >>>>>>>>like
> > >> >> > >>>>>>>>a
> > >> >> > >>>>>>>> > good chunk of the calendar time is getting folks to
> tag
> > >> their
> > >> >> > >>>>>>>>platform.
> > >> >> > >>>>>>>> > Ideally the promotion from rc to final should take
> very
> > >> >> little
> > >> >> > >>>>>>>>effort
> > >> >> > >>>>>>>> time.
> > >> >> > >>>>>>>> >
> > >> >> > >>>>>>>> > What I like about the rc is that it provides a
> settling
> > >> >> > >>>>>>>>mechanism
> > >> >> > >>>>>>>>for the
> > >> >> > >>>>>>>> > churn to calm down, run tests across more integration,
> > and
> > >> >> see
> > >> >> > >>>>>>>>the bigger
> > >> >> > >>>>>>>> > picture to assess release readiness. I would expect
> that
> > >> the
> > >> >> > >>>>>>>>promotion
> > >> >> > >>>>>>>> from
> > >> >> > >>>>>>>> > edge to rc should take a decent amount of effort time,
> > but
> > >> >> not
> > >> >> > >>>>>>>>because of
> > >> >> > >>>>>>>> > the "cut" activities.
> > >> >> > >>>>>>>> >
> > >> >> > >>>>>>>> > So when we are at rc and don't find any surprises, why
> > >> does
> > >> >> it
> > >> >> > >>>>>>>>take a
> > >> >> > >>>>>>>> week
> > >> >> > >>>>>>>> > to promote to final? If we spend a week in rc1,
> another
> > >> week
> > >> >> in
> > >> >> > >>>>>>>>rc2, and
> > >> >> > >>>>>>>> > another week to cut final, that leaves only 1 week in
> a
> > >> >> 4-week
> > >> >> > >>>>>>>>cycle for
> > >> >> > >>>>>>>> > active dev work?
> > >> >> > >>>>>>>> >
> > >> >> > >>>>>>>> > I like the ideal of a channel/stream/branch/whatever
> > where
> > >> >> there
> > >> >> > >>>>>>>>is a
> > >> >> > >>>>>>>> > place for the rc to settle without necessarily
> blocking
> > >> >> commits
> > >> >> > >>>>>>>>to edge.
> > >> >> > >>>>>>>> > Where I'm going with this is that if there is an area
> > >> where
> > >> >> > >>>>>>>>commits to
> > >> >> > >>>>>>>> the
> > >> >> > >>>>>>>> > rc are carefully controlled, then perhaps one person
> > (i.e,
> > >> >> Steve
> > >> >> > >>>>>>>>G) could
> > >> >> > >>>>>>>> > cut the release for ALL platforms using scripts. This
> > may
> > >> >> > >>>>>>>>involve
> > >> >> > >>>>>>>>that
> > >> >> > >>>>>>>> one
> > >> >> > >>>>>>>> > person tagging/branching/whatever across multiple
> > >> platforms.
> > >> >> > >>>>>>>> >
> > >> >> > >>>>>>>> > I also like putting the "how to cut" magic in each
> > >> platform.
> > >> >> > >>>>>>>>Then
> > >> >> > >>>>>>>>perhaps
> > >> >> > >>>>>>>> > a good chunk of coho is tests to make sure that the
> > >> platform
> > >> >> > >>>>>>>>magic
> > >> >> > >>>>>>>> > delivered the correct format to it.
> > >> >> > >>>>>>>> >
> > >> >> > >>>>>>>> > -- Marcel Kinard
> > >> >> > >>>>>>>> >
> > >> >> > >>>>>>>>
> > >> >> > >>
> > >> >> >
> > >> >> >
> > >> >>
> > >> >
> > >> >
> > >>
> > >
> > >
> >
>

--047d7b10cbcb3249fd04d25a78c1--