incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Kinsella <...@stratosec.co>
Subject Re: ASF repo tags
Date Wed, 04 Jul 2012 19:08:37 GMT
On Jul 4, 2012, at 11:18 AM, David Nalley wrote:
> On Wed, Jul 4, 2012 at 1:49 PM, John Kinsella <jlk@stratosec.co> wrote:
>> Can we add git tags for the 3.0.0, 3.0.1, and 3.0.2 releases? I realize they're not
ASF-blessed releases, but would be very handy for when folks want to grab a particular release
from the repo.
>> I think 3.0.0 is cf0a4e02743abb87b665ea585cb3cf1786c4d966? The zip file on sf.net
mentions bcc4833 but I don't see that as a rev. I haven't tracked down the other two, yet.
> There in lies the problem.
> Typically the branching methodology would work something like this:
> 
> master would be where cutting edge development would happen - for
> really big features or major rewrites
> Each release series would have it's on branch 3.0.x for the 3.0 series
> and 2.2.y for the later 2.2 series.
> Features would be introduced into those branches directly (and
> cherrypicked into master).
> As a release drew near, each release would branch as well so ongoing
> work could happen as well. So you'll see branches in the old repo for
> 3.0.{1,2,3} etc. During this phase work should be checked into 3.0.2,
> 3.0.x, and master.

I agree with the idea of branches for point releases (3.0,3.1,3,2..) but not sure we need
separate branches for minor releases? I guess it comes back to what CS agrees to maintain
and for how long. With the current wording on http://wiki.cloudstack.org/display/COMM/Draft%3A+CloudStack+Maintainers+Guide,
we're not doing any maintenance on releases, but fixing issues going forward...

> However, several factors complicate that. First,
> not all patches applied cleanly as the three different codebases were
> often in very different places. Second, people are human, and I
> imagine some commits just didn't make it.

Sounds like something a tool would help with, but I don't know of said tool…plugin for Jenkins,
maybe? Seems like it shouldn't be too hard to look for similar commits to 2 different branches.

Would this maybe be something that falls under a Maintainer to manage? e.g. for the Agent
Maintainer, make sure /agent patches are applied to the last 3 release branches?

Branch management may take us a little more work, but I think it'd be pretty easy as part
of release management to tag the revision that was used to build that release...

John

Mime
View raw message