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.
