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 brian.leroux@gmail.com
 designates 209.85.212.50 as permitted sender)
MIME-Version: 1.0
Sender: brian.leroux@gmail.com
In-Reply-To: 
 <CAEeF2Te-qM-CfcOvP7gg44VCVwUtzH-_iS3hKcPxg3OSHcdwWw@mail.gmail.com>
References: 
 <CADVgkyMARACG6CDC0t+ZTWSbHqfCbs06egPJ7EkLBWkOJgAQuA@mail.gmail.com>
	<50D22549.50801@gmail.com>
	<CABiQX1UNGm_1h+3UPePrcu64uTCzFHrzF8cX-b7xBa=Kd8dWtA@mail.gmail.com>
	<CAEeF2Te-qM-CfcOvP7gg44VCVwUtzH-_iS3hKcPxg3OSHcdwWw@mail.gmail.com>
Date: Thu, 20 Dec 2012 10:23:25 -0800
Message-ID: 
 <CADVgkyOcC4gVErugJtoxehUtR_S4U5r-PvaXPLkP6SxegpZVZQ@mail.gmail.com>
Subject: Re: too long to package a release?
From: Brian LeRoux <b@brian.io>
To: dev@cordova.apache.org
Content-Type: text/plain; charset=ISO-8859-1

I suspect the real issue here is the shared dependency on cordova.js
which is, at least for now, a neccessary evil. (Once we move to a
light core and plugin all the things this should be way less surface
for hurt since plugins will, I'm going to assume/propose, become
independently versioned.)

But this does raise some interesting thinking. In a sense we treat our
tags like channels are treated in chrome.

X.X.XrcX === Beta
master === Dev
X.X.X === Stable

Except tags are static whereas channels are more like branches. Thus
the re-tag dance. We could consider moving to more than once long
lived branch. (Tho this would not solve cordova.js needing to be
tagged.)


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