Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (herse.apache.org: domain of jason.dillon@gmail.com
 designates 66.249.92.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
        b=G+VPU9Ki8XWQQZ5W1swoPhrY7wr3HmVM/y+P6fZ5Z5iqmSFmun4+o0TWiawpnz3A4NNcpNzAEurwsu78EnyqwPUUMObhxb5PT92FDoKvHJnQ4dJrxSVqqsuDMGyKP4h2uAQJX8rNh6jBFXXVPakKfr4Yt5X0mkIL53V4T65dm+w=
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <B0913E4A-530A-46D3-9153-A3E12DE5C711@hogstrom.org>
References: <20061218163525.270B51A981D@eris.apache.org>
 <E96FE893-BAC0-4D0B-BD76-7E4152C68F19@planet57.com>
 <B0913E4A-530A-46D3-9153-A3E12DE5C711@hogstrom.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <D1384A7B-5445-4AD8-AD1C-494F0086662F@planet57.com>
Content-Transfer-Encoding: 7bit
From: Jason Dillon <jason@planet57.com>
Subject: 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)
Date: Mon, 18 Dec 2006 16:18:53 -0800
To: dev@geronimo.apache.org
Sender: Jason Dillon <jason.dillon@gmail.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