cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Kluge <Kevin.Kl...@citrix.com>
Subject RE: ASF repo tags
Date Fri, 06 Jul 2012 21:23:39 GMT


> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Thursday, July 05, 2012 12:02 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: ASF repo tags
> 
> > How about this, just to define it (more or less what David just said):
> > * For development/feature branches, the developer(s) have a
> responsibility of making sure their code will cleanly merge back into master,
> either by keeping their branch in sync with master, or by doing any triage at
> time of merging their branch back to master when ready.
> > * The only time CS patches and releases an update for a release is in the
> event of a security vulnerability. If a vulnerability is found, the CS team will
> evaluate releases within the last 3 releases, and issue patches where
> necessary.
> > * Otherwise, patches will be applied to the master tree only.
> >
> 
> I am ok with this in principle. But let me toss another situation and see what
> your reaction is.
> Let's say we release 5.2.0 on Monday, and on Wednesday, we find an
> absolutely horrendous bug that would effect a large number of users.
> Would we still wait til 5.3.0 n-months down the road - or release
> 5.2.1 in a matter of a week(s)?
> 
> While I don't like the idea of maintaining multiple releases, there are
> occasions where it could make sense.

I agree, in that case we'd have to release a 5.2.1, otherwise the users will go somewhere
else.

I assume whoever was release manager for the 5.2.0 release would own the subsequent maintenance
releases -- including deciding whether or not there is one, and what goes in if there is one.
 I'm unclear on who would be expected to merge a given fix from master into the 5.2.x branch.
 Perhaps the release manager should create a ticket then assign it to whoever committed the
original patch?  So by committing a patch you agree to subsequently merge it into other branches
if asked to do so by a release manager in the project.

-kevin

Mime
View raw message