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 bowserj@gmail.com designates
 209.85.223.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CD09C58C.14C48%fil@adobe.com>
References: 
 <CADVgkyO9zmrB-sncvKq6Mjv_Mc9ERjoyopbiLV1g7TkF6PWKvA@mail.gmail.com>
	<CD09C58C.14C48%fil@adobe.com>
Date: Wed, 2 Jan 2013 11:19:57 -0800
Message-ID: 
 <CAOBL_k71Ye32BEgG=iiaHo1WEduWTakxBd+Be3-WgqrwF66yLQ@mail.gmail.com>
Subject: Re: too long to package a release?
From: Joe Bowser <bowserj@gmail.com>
To: dev <dev@cordova.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

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
>>>>>>> >
>>>>>>>
>