cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: on better release and version management
Date Fri, 19 Sep 2003 09:25:51 GMT
Steven Noels wrote:
> 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.
> The Release Manager him/herself is also only allowed to commit obvious 
> version number changes and all that during this two-day "Sperr-zone".
> 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.

(PS: I always checked and rated (or better tried to) every commit in the 
last two/three days before the release, if they could do harm. But that's
of course no guarantee.)

> 2) We need to break from the impasse of 2.1.1 vs 2.2

I tried to address this issue several times in the last weeks, well, 
without much success.
One thing I want to stress again: *if* we would make a new repository
for 2.2 and duplicate all code, this would include the blocks as well.
So we would not only end up with the two versions to maintain for the core
but for each and every block as well! 
And this makes imho no sense. It's ok for the core, if we say 2.1 is only 
bug-fixing from now on. But it makes absolutely no sense for blocks. 
I think the development of blocks should be independent from the
development of the core. With duplicating the code we loose this.

So, whatever we decide, I'm -1 on duplicating the block code.

> 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) and go for a new target release date for 2.1.2 on 
> September 24th. 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.
I have not followed all mails in the last ten days (as I was on holidays),
so what's the current state here?
I just checked that I'm able to do a 2.1.2 release from my couch here
at home although I still enjoy my vacation (as long as the VPN to my
company is working). So if required I can do the release next week.

Now to the docs:
Yes, looking back it was a very stupid idea to reorganize the docs. I
didn't thought about links pointing to the old docs. I'm very sorry
for that!

To my defense I have to say, that originally I wanted to write an
"online book" as a getting started manual for cocoon. I wanted to use
the existing docs as a starting point, rearrange them and enhance them
to get a complete guide. My first idea was to host this somewhere
else than the cocoon cvs to avoid any problems. But then I came
to the conclusion that this wouldn't be so wise and that this
might lead to some nice flame wars and writing of long emails. Bah.
So, I thought, why not starting this in the cocoon cvs? I wrote
a ten page intro, rearranged the parts and managed to delete every-
thing accidentally.........damn......ok, to keep a boring story
short: then I decided to just rearrange everything and commit it
if noone is against it (that's why I asked on the list before).

Ok, but I think this shows a general problem (perhaps for forrest?):
What do to if you move a document?

I'm just thinking of adding a "moved" doc at the old place. Example:
you move a "index.xml" from directory a to b. You add the moved
document at the old place, so you end up with this:
- a + index.moved
- b + index.xml
The index.moved is a text (xml?) doc, containing the new location.
If someone requests the old document (a/, forrest detects
the index.moved file and makes a redirect.
This is just a rough idea. What do you think?

If you all want, I could try to reinstantiate the old doc structure,
this will take some days, but it's possible. It's my fault that we
have this situation now, and I'm willing to do everything possible
to fix it again.


View raw message