Release Guidlines (was: Re: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml)

[Matt Hogstrom <ma...@hogstrom.org>]

On Dec 18, 2006, at 3:45 PM, Jason Dillon wrote:

> Ugh... this is why I don't like all that moving of branches to tags...
>

I agree

> A "tag" or "label" should never be modified... its a point in time,  
> not indented (or expected) to be changed.
>
> I believe that we would be doing ourselves a major favor by  
> following some SCM best practices... moving branches to tags is not  
> one of them... neither is changing code in a tag.
>

Dain ran into a similar problem where while releasing he had an issue  
that a utility as part of the release process caused him to make a  
change to source because of a variable name.

For the milestone I'm not concerned but I am concerned that we get  
the release process documented and agreed to.  We're not going to fix  
these two release processes.

I am writing up on the CWiki my thoughts for release that I'd like to  
get ironed out BEFORE we get to the next release.  Not that we've  
done anything wrong but I feel this process is too fluid as we've  
changed it almost every release.  This includes changes to voting,  
releasing, and build tools.  We've worked through them each time and  
no process will be perfect but we should be refining something each  
time and not creating something new.

Here are my list of items to start with:

Define release in terms of Milestone, Beta, Full Version
- includes definition of user expectations
- quality of the release
- logging level consistency
- Release Notes content
- Packing list for delivered content
- Naming conventions for delivered modules (ala manually created source)

Process of branching and tagging (we already have  a plethora of  
discussion...I think this needs to get on a Wiki)
- includes tags and modifications

Including non-released artifacts and how they are handeled and where  
they go

Voting time lines and expectations
- Things like VOTE and DISCUSS threads
- when do they get restarted (or do they)...how to handle issues like  
changes to the tree that were no previously caught
- Is there a limit where the 72 hour timeline is satisfied previously?

Ok, these are a few of my favorite things.  Actually, this is a lot  
of process but to Jason's concern (which I agree with) we need to  
lock this down.

Matt Hogstrom
matt@hogstrom.org

Re: Release Guidlines (was: Re: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml)

[Matt Hogstrom <ma...@hogstrom.org>]

On Dec 18, 2006, at 10:37 PM, Jason Dillon wrote:

> For the M1 release I would have said close enough and made the  
> final release from trunk.
>
> But changing the tag is harmful by itself by setting precedence...  
> something which should not be followed, yet unless people  
> understand why, they will just continue along those bad practices.
>
> And technically speaking, making a change to a branch or hacking up  
> a tag should have the exact same effect on any work that anyone  
> might need to redo for a release.  And really we could thump the  
> rule book on the ci to tags too... which is pointless for this  
> release.  The important thing is that people understand that its  
> not appropriate to alter a "tag" in that manner.  This is a pure  
> policy argument, as technically from the release perspective is  
> identical using svn, in both cases, the release must be re-cut, re- 
> approved, blah, blah, blah.  And in general for release tags, it is  
> best to treat them as read only.
>

We're all on the same page...I weighed the change versus lost sleep  
and my marriage.  The commit won :)

> --jason
>
>
> On Dec 18, 2006, at 5:53 PM, David Blevins wrote:
>
>>
>> On Dec 18, 2006, at 2:59 PM, Matt Hogstrom wrote:
>>
>>> Process of branching and tagging (we already have  a plethora of  
>>> discussion...I think this needs to get on a Wiki)
>>> - includes tags and modifications
>>
>> Discussion, proposal, resolution and final vote.
>>
>> http://cwiki.apache.org/GMOxPMGT/release-branching-process.html

Thanks David...this is what I was referring to and I don't think we  
need to go through it again.  I forgot it made it to the Wiki.

>>
>> Granted that was June, just about time to do it all over again :)
>>
>> In regards to the commit to the tag, I don't have a problem with  
>> it as it was completely ineffectual in any technical sense.  We  
>> could of course thump the rule book and make Matt redo 8+ hours of  
>> work and have days worth of revoting followed up by a couple weeks  
>> worth of cumulative man hours on policy discussions... or we could  
>> just say "close enough" and focus on 2.0-M2.
>>
>> -David
>>
>>
>
>

Matt Hogstrom
matt@hogstrom.org

Re: Release Guidlines (was: Re: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml)

[Jason Dillon <ja...@planet57.com>]

For the M1 release I would have said close enough and made the final  
release from trunk.

But changing the tag is harmful by itself by setting precedence...  
something which should not be followed, yet unless people understand  
why, they will just continue along those bad practices.

And technically speaking, making a change to a branch or hacking up a  
tag should have the exact same effect on any work that anyone might  
need to redo for a release.  And really we could thump the rule book  
on the ci to tags too... which is pointless for this release.  The  
important thing is that people understand that its not appropriate to  
alter a "tag" in that manner.  This is a pure policy argument, as  
technically from the release perspective is identical using svn, in  
both cases, the release must be re-cut, re-approved, blah, blah,  
blah.  And in general for release tags, it is best to treat them as  
read only.

--jason


On Dec 18, 2006, at 5:53 PM, David Blevins wrote:

>
> On Dec 18, 2006, at 2:59 PM, Matt Hogstrom wrote:
>
>> Process of branching and tagging (we already have  a plethora of  
>> discussion...I think this needs to get on a Wiki)
>> - includes tags and modifications
>
> Discussion, proposal, resolution and final vote.
>
> http://cwiki.apache.org/GMOxPMGT/release-branching-process.html
>
> Granted that was June, just about time to do it all over again :)
>
> In regards to the commit to the tag, I don't have a problem with it  
> as it was completely ineffectual in any technical sense.  We could  
> of course thump the rule book and make Matt redo 8+ hours of work  
> and have days worth of revoting followed up by a couple weeks worth  
> of cumulative man hours on policy discussions... or we could just  
> say "close enough" and focus on 2.0-M2.
>
> -David
>
>

Re: Release Guidlines (was: Re: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml)

[David Blevins <da...@visi.com>]

On Dec 18, 2006, at 2:59 PM, Matt Hogstrom wrote:

> Process of branching and tagging (we already have  a plethora of  
> discussion...I think this needs to get on a Wiki)
> - includes tags and modifications

Discussion, proposal, resolution and final vote.

http://cwiki.apache.org/GMOxPMGT/release-branching-process.html

Granted that was June, just about time to do it all over again :)

In regards to the commit to the tag, I don't have a problem with it  
as it was completely ineffectual in any technical sense.  We could of  
course thump the rule book and make Matt redo 8+ hours of work and  
have days worth of revoting followed up by a couple weeks worth of  
cumulative man hours on policy discussions... or we could just say  
"close enough" and focus on 2.0-M2.

-David

Re: Release Guidlines (was: Re: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml)

[Jason Dillon <ja...@planet57.com>]

On Dec 18, 2006, at 2:59 PM, Matt Hogstrom wrote:
> Dain ran into a similar problem where while releasing he had an  
> issue that a utility as part of the release process caused him to  
> make a change to source because of a variable name.

Was this before or after the release tag was made?  Can you elaborate  
on this?  Or maybe Dain can, so that I can understand better.

I know of several issues with the release plugin, I actually think  
that its only useful as part of an automated release solution, still  
need some additional build help and sanity checks to ensure that when  
its time to make a release, that everything is going to be happy.


> For the milestone I'm not concerned but I am concerned that we get  
> the release process documented and agreed to.  We're not going to  
> fix these two release processes.

I  agree, though I hope we can fix some of these issues before M2  
goes out.

My point about the ci to tags however could have been avoided, by  
keeping the branch (not moving it to tags) and then copying to label,  
as is the recommended method to label things in svn.  It was also  
more general that relating to releases... generally assume that a tag  
is read-only.  Don't mv a branch to a tag, copy it.


> I am writing up on the CWiki my thoughts for release that I'd like  
> to get ironed out BEFORE we get to the next release.  Not that  
> we've done anything wrong but I feel this process is too fluid as  
> we've changed it almost every release.  This includes changes to  
> voting, releasing, and build tools.  We've worked through them each  
> time and no process will be perfect but we should be refining  
> something each time and not creating something new.

Well, I think a ci to a tag *was* wrong :-P  But other than that I  
basically agree.


> Here are my list of items to start with:
>
> Define release in terms of Milestone, Beta, Full Version
> - includes definition of user expectations
> - quality of the release

Yikes... not sure what either of these might actually be... can you  
give an example of what these might look like for 2.0-M1?


> - logging level consistency

Um... you know that this one will differer based on which user  
consumes it right?  Open-source-savvy user might expect INFO, where  
Joe-consumer-embedder, might expect its ERROR (and both may flag it  
as broke if its not what they expected).

Not sure who the default release configuration should be tailored  
to... and god no... I'm not suggesting we make a release for each of  
them :-P


> - Release Notes content

Yes, this is important... and IMO should be driven off of JIRA for  
that version as well as including detail about specific changes.

I think that the AMQ folks do this well... as well as that Atlassian  
folks.  I recommend we copy them.


> - Packing list for delivered content

Eh, I don't care too much about this really.  Though if it can be  
automated, then maybe it okay, else I see this as a non-important  
document which will quickly become out of date, and out of date  
documented is more harmful than it is useful.  Though a general  
README.txt which explains the basic top-level directories should be  
good, and easy to maintain.


> - Naming conventions for delivered modules (ala manually created  
> source)
>
> Process of branching and tagging (we already have  a plethora of  
> discussion...I think this needs to get on a Wiki)
> - includes tags and modifications

Yes, it should... though the svn book covers most of this, I don't  
recommend we drift to far from it.


> Including non-released artifacts and how they are handeled and  
> where they go

Its been almost 6 months and I am still staying the same thing... we  
need our own repo, backed our svn, which can contain these bits... as  
the time to wait for other projects to release is crazy (especially  
if they too are ASF projects bound by the same style of release hell).

Having our own svn backed repo allows us to always have the right  
versions of artifacts, labeled with our source, which helps increase  
the changes that codelines are buildable far into the future.  And  
even if our repo is only subset, and the rest are pulled from central  
for starting out, we are in a better position.  Even better to have  
*everything* in our svn repo, but that might be more work to  
implement than any of us have time right now.


> Voting time lines and expectations
> - Things like VOTE and DISCUSS threads
> - when do they get restarted (or do they)...how to handle issues  
> like changes to the tree that were no previously caught
> - Is there a limit where the 72 hour timeline is satisfied previously?

NOTE, if our release process was automated, then the time/effort to  
build a release would be minimal.  We could easily spin off a  
"<version>-VOTING-<n>" build, and then once it passes, simply rebuild  
the exact same thing as a final.  This is one significant advantage  
to building off of source control (either be it sources, or binaries  
checked in).  But with that and an automated process, you can take a  
previous VOTING build and reproduce it exactly, changing only the  
version... and have a high degree of trust that it is going to behave  
the same... backed up by svn's change logs to show what was actually  
changed.

I still think the whole voting delay is silly... but oh well... I  
guess it similar to cutting a build for QA, then QA pounds on it for  
a week, and either blesses or rejects it.  But IMO that happens  
before a "release", when it comes time to actually make a release, it  
should already have passed the requirements, voting, blah, blah.  And  
you simply rebuild the project from the revision that has been  
officially blessed.  IMO it is backwards to bless the binaries...  
when it should be the source code that is blessed.

--jason