[#33640] [Ruby 1.9-Bug#4136][Open] Enumerable#reject should not inherit the receiver's instance variables — Hiro Asari <redmine@...>

Bug #4136: Enumerable#reject should not inherit the receiver's instance variables

10 messages 2010/12/08

[#33667] [Ruby 1.9-Bug#4149][Open] Documentation submission: syslog standard library — mathew murphy <redmine@...>

Bug #4149: Documentation submission: syslog standard library

11 messages 2010/12/10

[#33683] [feature:trunk] Enumerable#categorize — Tanaka Akira <akr@...>

Hi.

14 messages 2010/12/12
[#33684] Re: [feature:trunk] Enumerable#categorize — "Martin J. Dst" <duerst@...> 2010/12/12

[#33687] Towards a standardized AST for Ruby code — Magnus Holm <judofyr@...>

Hey folks,

23 messages 2010/12/12
[#33688] Re: Towards a standardized AST for Ruby code — Charles Oliver Nutter <headius@...> 2010/12/12

On Sun, Dec 12, 2010 at 9:55 AM, Magnus Holm <judofyr@gmail.com> wrote:

[#33689] Re: Towards a standardized AST for Ruby code — "Haase, Konstantin" <Konstantin.Haase@...> 2010/12/12

On Dec 12, 2010, at 17:46 , Charles Oliver Nutter wrote:

[#33763] [Ruby 1.9-Bug#4168][Open] WeakRef is unsafe to use in Ruby 1.9 — Brian Durand <redmine@...>

Bug #4168: WeakRef is unsafe to use in Ruby 1.9

43 messages 2010/12/17

[#33815] trunk warnflags build issue with curb 0.7.9? — Jon <jon.forums@...>

As this may turn out to be a 3rd party issue rather than a bug, I'd like some feedback.

11 messages 2010/12/22

[#33833] Ruby 1.9.2 is going to be released — "Yuki Sonoda (Yugui)" <yugui@...>

-----BEGIN PGP SIGNED MESSAGE-----

15 messages 2010/12/23

[#33846] [Ruby 1.9-Feature#4197][Open] Improvement of the benchmark library — Benoit Daloze <redmine@...>

Feature #4197: Improvement of the benchmark library

15 messages 2010/12/23

[#33910] [Ruby 1.9-Feature#4211][Open] Converting the Ruby and C API documentation to YARD syntax — Loren Segal <redmine@...>

Feature #4211: Converting the Ruby and C API documentation to YARD syntax

10 messages 2010/12/26

[#33923] [Ruby 1.9-Bug#4214][Open] Fiddle::WINDOWS == false on Windows — Jon Forums <redmine@...>

Bug #4214: Fiddle::WINDOWS == false on Windows

15 messages 2010/12/27

[ruby-core:33598] Re: [Ruby 1.9-Feature#4085][Open] Refinements and nested methods

From: Urabe Shyouhei <shyouhei@...>
Date: 2010-12-06 14:48:52 UTC
List: ruby-core #33598
(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.

In This Thread