(08/23/2011 09:20 PM), Lucas Nussbaum wrote:
> On 23/08/11 at 20:38 +0900, Urabe Shyouhei wrote:
>> Hello Lucas.
>>
>> (08/23/2011 08:09 PM), Lucas Nussbaum wrote:
>>> I think that the current way of managing branches and releases of Ruby
>>> is not optimal.
>>
>> Indeed.  But I'm not sure if Linux-style release management works in this
>> project.  Ruby is Ruby, not Linux.  Almost no programmers (except Matz) had
>> been paid to run this project until recently.  I doubt a 6-month release
>> cycle could hardly work for a hobby project like this.
> 
> Interesting. Why do you think so?

Because we once tried this: in the age of 1.8.2 through 1.8.5 (-p0).  We
observed that 6 months are a bit too short for a new toy.  Relatively few
people were going to look at forthcoming releases, which led many last-minute
push to them, and thus, result in poor quality.

A hobby is a hobby because no one forces you to meet a deadline.

> I don't really see a link between shorter release cycles and being able
> to work full time on a project. It's true that it is easier to meet
> deadlines when you work full-time on a project, but on the other hand,
> shorter release cycles releave some pressure from developers, because,
> if a feature can't make it into release 'n', it can still make it into
> release 'n+1' which will be released in 6 months (and not in two years).

Full-timer or not is not that important.  The point is we need something
different from employee management. 6 months are too long for a bug to be
fixed, while a bit too short for a hobbyist to look at.

It might be good for a feature like you say, but you know, man shall not live
by feature alone.