All of the points in this thread are valid, I trust those of you taking the lead on this part of the process will do a good job. I will get grumpy if the RC resembles "hey, I think the trunk is ready to go".
As you go about this process, please keep in mind that testing is unfortunately the bottleneck because there are so few (one?) running the suite. It also slows us down when the core has to be fixed by someone other than the individual who accidently made it incompatible ( which doesn't make you a bad person ). Just remember, the unit tests will never catch these. Often the communication breaks down because we can't talk about the tests on the public list or issue tracker. All of this can be improved by getting more committers to sign the TCK NDA and subscribing to the [EMAIL PROTECTED] list. All of this can be improved by getting more committers to sign the TCK NDA and subscribing to the [EMAIL PROTECTED] list. All of this can be improved by getting more committers to sign the TCK NDA and subscribing to the [EMAIL PROTECTED] list. All of this can be improved by getting more committers to sign the TCK NDA and subscribing to the [EMAIL PROTECTED] list. All of this can be improved by getting more committers to sign the TCK NDA and subscribing to the [EMAIL PROTECTED] list. I can test quite a bit from tomorrow until Sunday. Dennis Byrne >-----Original Message----- >From: Craig McClanahan [mailto:[EMAIL PROTECTED] >Sent: Thursday, July 13, 2006 02:55 PM >To: 'MyFaces Development' >Subject: Re: Testing for CoreRelease114 > >On 7/13/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: >> >> > Dennis, when and what are you testing? Shouldn't we tag and build it >> > as 1.1.4 first? >> >> why tagging, when the *snapshot* might be crap ? >> >> :-) > > >I agree with Wendy. Release votes should be about "here is a bunch of bits >that I propose we release as version x.y.z" -- not "hey, I think the trunk >is ready to go." The latter leaves open the possibility for several sorts >of problems: > >* Packaging problems that aren't apparent until the release > manager actually performs an "assembly" build or whatever. > >* Mistakes on the part of the release manager, that lead to > building something different than what the committers thought > they were voting on. > >* Differing assumptions about exactly what assembly steps > the release manager will do, versus what you (as a developer) > might expect. > >I've seen enough issues like this across multiple Apache projects that I >will now generally -1 any release where I'm a committer unless the proposal >is for a specific set of bits someone has posted in a test repository or >personal home directory for examination. > >Three other points: > >* Subversion tags are effectively free -- Subversion > operates on a "copy when modified" principle so > there is essentially no overhead. > >* Tertiary version numbers (the "z" in "x.y.z") are > also effectively free, but it is extremely important > to never release a non-snapshot x.y.z and then > change it later. Therefore, if testing of a release > candidate finds problems, throw it away and > go build the next one. > >* Doing the TCK testing on core should certainly > occur on the proposed release bits, but it is also > useful for someone to run them earlier against the > trunk build also, in an attempt to catch compatibility > issues earlier rather than later. > >-Matthias > > >Craig > > >> I'm making this up as I go along, referring to >> > http://wiki.apache.org/myfaces/Release_Procedure as necessary. :) >> > >> > IMO steps 5-6-7 are out of order. We should be voting on an actual >> > set of files, not a revision number in svn, and we should be testing >> > exacly those files before releasing them. >> > >> > There's a recent thread on [EMAIL PROTECTED] about voting on tarballs vs. >> > the >> > state of the svn tree. >> > http://www.mail-archive.com/[email protected]/msg06219.html >> > >> > Thanks, >> > -- >> > Wendy >> > >> >> >> -- >> Matthias Wessendorf >> >> further stuff: >> blog: http://jroller.com/page/mwessendorf >> mail: mwessendorf-at-gmail-dot-com >> >
