Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
From: "Reinhard Poetz" <reinhard@apache.org>
To: <dev@cocoon.apache.org>
Subject: RE: on better release and version management
Date: Wed, 10 Sep 2003 11:26:21 +0200
Message-ID: <001501c3777d$992a00f0$1e01a8c0@WRPO>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <3F5EE30E.4070801@outerthought.org>


From: Steven Noels

> Hi folks,
> 
> forgive me for putting on my BOFH hat, while making the following 
> observations...
> 
> 1) We suck at freezing and stabilizing the codebase prior to releases.
> 
> I would suggest that, from now on, the Release Manager puts forward a 
> release date after discussion on the dev list, and that there's a 
> two-day (!) freeze period where only glaring bugs can be 
> fixed after a 
> vote (!) on the list.

+1

> 
> The Release Manager him/herself is also only allowed to 
> commit obvious 
> version number changes and all that during this two-day "Sperr-zone".

+1

> 
> During the past few releases, there was a flurry of quick fixes and 
> commits happening just hours before Carsten made the tarball, 
> and while 
> I'm not immediately aware of any nasty side-effects caused by 
> this, it 
> sure doesn't look like there was time for any peer review on 
> these late 
> commits, neither did it look organized at all.
> 
> 2) We need to break from the impasse of 2.1.1 vs 2.2
> 
> I suggested yesterday night that the reshuffling of docs that Carsten 
> started really seems more apt for a 2.2 release. Also, the switch to 
> Fortress and Real Blocks are destined towards that 2.2 release. I 
> understand some Avalon peeps are glad to dive in and help us 
> with that, 
> which is great, but we should facilitate them.

Yep, I have the same concerns.

> 
> Some people want to start with a 2.2 CVS module right away, 
> others seem 
> more relunctant and want the HEAD of 2.1 to evolve into 2.2. 
> We need to 
> decide on this, since it's blocking progress.

Carsten made a good proposal how we can continue having 3 repositories
and how this can be done with only little code duplicating:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106076740711234&w=2

I'm +1 with his proposal - the reason is simple: Some people (and
customers too!) asked me if we have gone crazy and how they can update
Cocoon in the future without being alpha/beta-tester for 'real' blocks
and Fortress. We *must* be able to maintain 2.1 without all new features
like blocks and Fortress because IMNSHO these steps are to big for 2.1
and I'm -1 on the changes in the current repository.

(the -1 is of course no veto only a vote! BTW: Do we have voting
guidelines?)

> My personal opinion is that 2.2 might warrant its own module, but we 
> need to discuss its structure and coexistence with old-style 
> blocks code 
> in more depth before we ask for its creation to the 
> infrastructure peeps.
> 
> 3) Given the breakage in the Rhino stuff, and the lack of serious 
> testing on the 2.1.1 release, I would refrain from announcing 
> 2.1.1 (not 
> retracting it, though) 

Technically it has been released and I think many users monitoring our
lists are already using it. But a release is a release ... So +1 for
leaving it where it is but we should add a warning to the dowload pages
and we should send an 'official' mail having a subject like "Cocoon
2.1.1 unstable" to our mailling lists.

> and go for a new target release date 
> for 2.1.2 on 
> September 24th. 

I would prefer a release next week. I can help with tests.

> That way, we can discuss at leisure what we 
> are going to 
> do with the docs-reshuffling, and people can spend more time 
> on testing 
> new stuff.
> 
> Please comment!

Additionally we have to think more about auto-testing our code. We have
some good unit tests and an Anteater script but that's not enough as we
have seen with 2.1.1.

Would it be enough to extend our Anteater scripts (see Guido's mail) and
add Anteater to our codebase and include it automatically to our build
system? 

So my question is: What kind of problems can't be found with
- unit tests
- regression tests?

BTW, unfortunatly the latest Anteater release needs Java 1.4.x ...

Cheers,
Reinhard


> 
> </Steven>
> -- 
> Steven Noels                            http://outerthought.org/
> Outerthought - Open Source Java & XML            An Orixo Member
> Read my weblog at            http://blogs.cocoondev.org/stevenn/
> stevenn at outerthought.org                stevenn at apache.org
>