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 Fri, 06 Jul 2012 22:07:01 GMT
On Jul 6, 2012, at 2:23 PM, Kevin Kluge wrote:
>> -----Original Message-----
>> From: David Nalley [mailto:david@gnsa.us]
>>> 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.

Sorry - forgot to respond to David's last message - I'll blame the cold medicine…

I concur that a new minor point release should be created in that case. Regarding how to get
the patch applied to branches - I'd like to think the release manager and patch contributor/committer
would work together - if it's a simple patch, release manager should be able to apply it.
If it's something more complex, I'd like to see the two work together.

John

Mime
View raw message