(2010/12/06 21:17), Charles Oliver Nutter wrote:
> On Sat, Dec 4, 2010 at 6:32 AM, Shugo Maeda <shugo / ruby-lang.org> wrote:
>>> Note that this is just my opinion, and that I seem to be in the
>>> minority ;-)
>>> I hope that 1.9.x would be stable, but many other committers seem to
>>> hope to include new feature in 1.9.x aggressively.
>>
>> I also hope that 1.9.x would be stable, but I'd like to develop
>> aggressively in trunk.  I don't think the current design and
>> implementation of refinements are mature, but I can't make them mature
>> on my own, so I'd like to have help from other committers.
> 
> This is what topic branches are for :)

No.  That idea is not a SVN way.  A trunk in SVN is an actively developed edge
branch.  In contrast a master branch in Git is a merged collection of topic
branches, thus they are far less active than SVN trunk.  So in SVN,
developments goes on the trunk.

> I don't believe refinements
> should land on trunk, since it's not yet clear whether they should be
> included at all.

I think it's all what you tell.  You just don't like it, do you?

> Landing them now, making multiple additional commits
> to them, and propagating their changes throughout other
> subsystems...all will make it harder to roll back Refinements if it is
> decided they shouldn't get into standard Ruby.

You say "now" ... Do you believe it gets easier to roll back as time goes?  I
don't think so.  If it's a matter of time I can agree with you but...

> I think everyone knows how to check out an alternative branch or
> repository :) If they would like to assist you (and you would like
> them to assist you) they can do it that way. 

Life is much easier if everyone assisted me testing our ruby_1_8_7 branch
every day.  Did you know I'm planning a patchlevel release this month?  Have
you compiled it and run tests?  So far all who actually assisted me was Luis
Lavena only.

No, I'm not blaming you.  It's all as usual.  Assistance won't happen until
someone gets some trouble.

> It shouldn't be done on
> mainline, in my opinion, until it has solidified a bit more and it's
> certain to be included in an upcoming "standard" Ruby release.

Define your "a bit more".  Otherwise you can reject a new feature as many time
as you want with this exact phrase.