httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guenter Knauf <fua...@apache.org>
Subject Re: [VOTE] The 'RM' Baton
Date Wed, 10 Jul 2013 22:30:28 GMT
On 10.07.2013 15:22, Jim Jagielski wrote:
> Considering that I've been the only RM for 2.4.x, I can't help but
> assume that Bill is referring to me.
>
> As mentioned by others, by indicating a desire to T&R, it energizes
> people to catch up on STATUS, place their votes and propose backports.
> So it is *expected* that at a time when things should be the most
> "stable" (right before a "release"), that there is a flurry of
> activity. So what if it means a delay of a few weeks or even a month.
> The result is a *better* release for our users, which I think is
> even more important.
well, but this concept is IMO not very efficient; often it happend that 
things were then backported in a rush to get things in with *this* 
pending release, and afterwards shows that it broke something on 
platforms which are not in the main focus (but that woudnt matter if we 
would release more often). Also it is not required for a new release to 
come with a ChangeLog of at least 10 entries - if we have only 5 then 
lets get the 5 to the users!

I was also thinking about learning how to release - but the lack of 
proper documentation for the whole process holds me back; I remember how 
Graham fell from one trap into another when he did his 1st APR release, 
and I dont want to get same ...
so, if we want to have more folks doing more frequently releases the 
startpoint would be to 1st document how a release is done:
- required auto* tools versions
- step by step description how to prepare for a release

what would also help here is a way to do a test-release ... ;-)

also I would be +++1 for making fix dates for releases, f.e. lets say 4 
times a year which means all 3 months - and then doing the release 
*REGARDLESS* if we have thing hanging in STATUS or not! What doesnt go 
into this release does make it for the next, and that would then only be 
3 months.
But I would *NOT* vote for such unless I'm self able to do releases.

As an example you may look at the libcurl project - we do there every ~2 
months releases; one month for committing new stuff, and another month 
for testing and only bugfixes + looking at our autobuilds to see any 
regressions.

Gün.



Mime
View raw message