ASF repo tags

[John Kinsella <jl...@stratosec.co>]

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.

John

Re: ASF repo tags

[Mohammad Nour El-Din <no...@gmail.com>]

Sorry did go through your e-mail first

that another matter which totally code management and it is up to the CS
community decide about

I tried to address the Apache blesses releases part of the message

Sent from my Samdung Galaxy S3
Apologies for any typos
On Jul 4, 2012 8:18 PM, "David Nalley" <da...@gnsa.us> wrote:

> On Wed, Jul 4, 2012 at 1:49 PM, John Kinsella <jl...@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.
> >
> > John
>
> 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. 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.
>
> I suppose one could go and do check the branches/tags and sync them,
> but it strikes me as a good bit of work.
>
> --David
>

Re: ASF repo tags

[David Nalley <da...@gnsa.us>]

On Thu, Jul 5, 2012 at 1:53 PM, Chiradeep Vittal
<Ch...@citrix.com> wrote:
>>
>>
>>
>>> 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?
>
> That does sound like a lot of work. Does this mean the maintainer asks the
> patch submitter to test against the last 3 release branches?
>


So that was the old workflow. The current workflow IIRC is that all
feature development happens in a topic branch with the aim of being
moved back into master. Theoretically I suppose we'll branch for a
release, but the idea is that releases should really come from master
and not have such a complex branching scheme, so with the rare
exception of a patching something in a release branch and then back to
master should be the only thing that really is any greater than just
patching master.


--David

Re: ASF repo tags

[David Nalley <da...@gnsa.us>]

> 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

I think that is up to us to define. (and iterate if it we find it doesn't work)

--David

Re: ASF repo tags

[John Kinsella <jl...@stratosec.co>]

Just for documentation purposes, I believe these are the 3 revisions for recent releases:

3.0.0 cf0a4e02743abb87b665ea585cb3cf1786c4d966
3.0.1 38d6ce4ef27a90354ea72c2366e1be74a7403536
3.0.2 5fda83b735d211ca5df614eb495b847a788027a3

Re: ASF repo tags

[John Kinsella <jl...@stratosec.co>]

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

RE: ASF repo tags

[Kevin Kluge <Ke...@citrix.com>]

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

Re: ASF repo tags

[David Nalley <da...@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.

--David

Re: ASF repo tags

[John Kinsella <jl...@stratosec.co>]

On Jul 5, 2012, at 10:53 AM, Chiradeep Vittal wrote:
>>> 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?
> 
> That does sound like a lot of work. Does this mean the maintainer asks the
> patch submitter to test against the last 3 release branches?

Good question. I don't think that'd have developers flocking to work on CS.

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.

John

Re: ASF repo tags

[Chiradeep Vittal <Ch...@citrix.com>]

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

That does sound like a lot of work. Does this mean the maintainer asks the
patch submitter to test against the last 3 release branches?

--
Chiradeep

Re: ASF repo tags

[John Kinsella <jl...@stratosec.co>]

On Jul 4, 2012, at 11:18 AM, David Nalley wrote:
> On Wed, Jul 4, 2012 at 1:49 PM, John Kinsella <jl...@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

Re: ASF repo tags

[David Nalley <da...@gnsa.us>]

On Wed, Jul 4, 2012 at 1:49 PM, John Kinsella <jl...@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.
>
> John

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

I suppose one could go and do check the branches/tags and sync them,
but it strikes me as a good bit of work.

--David

Re: ASF repo tags

[Mohammad Nour El-Din <no...@gmail.com>]

I don't think that tagging on the source code/repo level is a problem as
long as it is not announced as an Apache release or distributed under that
name

But they can merely be used as a tagged version of source code which
developers can use on their own responsibility

Also I believe it is better to mention somewhere, maybe as a disclaimer
file at the root of the tagged version [1], that this code does not
represent an Apache release and it is only can be used on users/developers
own responsibility

[1] other mentors would you please correct in that matter if I am mistaken ?

Sent from my Samdung Galaxy S3
Apologies for any typos
On Jul 4, 2012 7:50 PM, "John Kinsella" <jl...@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.
>
> John
>