[ruby-core:54221] Re: Encouraging use of CommonRuby

Em 12-04-2013 04:40, Charles Oliver Nutter escreveu:
> On Thu, Apr 11, 2013 at 3:50 PM, Marc-Andre Lafortune
> <[e-mail]>  wrote:
>> My thought is that all feature requests for trunk should be considered
>> Common Ruby.
>>
>> I'm not sure I see the point of having two separate "projects". What would a
>> "bug" in Common Ruby mean?
> Do you agree that Ruby and MRI are separate things? If so, we need to
> avoid filing bugs or features against MRI that would lead to changes
> in other Rubies.
>
> I gave examples of what would *not* be ComnonRuby in my repliy to
> naruse. If any implementation would need to implement said feature to
> be "compatible", it should be in ComnonRuby. If it can be reasonably
> defined as an MRI-specific change (env vars, RubyVM methods, build
> changes, cross-platform behavioral differences, ...) it would be fine
> to call a ruby-trunk issue.
>
> I recognize there's a grey area here. I also recognize that feature
> requests filed against ruby-trunk do not encapsulate similar visible
> feature changes that happen in other Redmine projects. We need one
> place where we can look up implenentation-impacting changes.
>
>> Can't you filter on the subject of the message for "Feature"?
>>
>> If so, I would simply merge Common Ruby into trunk
> I think there's a very clear line between MRI features and "Ruby"
> features. I need to know the latter in order to make JRuby as
> compatible as possible. I don't really care about the former.

I'm a bit confused here. I understand that MRI is different from Ruby 
but if you want to know which changes to Ruby should be also ported to 
JRuby it should be enough to run some common set of specs of a recent 
Ruby against the JRuby implementation, ideally.

If that is not enough, maybe we should try to improve such common test 
suite among different implementations.

But if otherwise you're interested in discussing such changes before 
they get approved by Matz but doesn't want to have to read all other MRI 
specifics tickets, then I feel your pain. Unfortunately I believe 
Redmine (nor even latest versions) support tagging tickets. If it 
allowed tagging them it would be just a matter of tagging such common 
tickets like "common" and "approved" and provide some news feeds 
interface so that you could look at them separately, although I still 
believe it would be hard anyway to get a quick overview of those tickets 
as they usually contain a lot of comments. So maybe it would be good if 
we could tag some tickets as "common Ruby" and whenever a ticket 
containing lots of comments get approved, maybe we should close that 
ticket, create a new one with the summary of what should be changed and 
reference the old ticket in case someone wants to look at the full log.

Just to let you know, Redmine maintainers are favorable to introducing 
issues tagging to Redmine:

http://www.redmine.org/issues/1448

So, if you believe that would help, maybe we could try to get this 
implemented in Redmine and start using the newest version...

Anyway, this is just an idea. I'm sorry since I said I would help 
updating Redmine but since my daughter is about to born any time now I 
can't find much free time to focus on this upgrade, although it 
shouldn't be that hard. I already tested that it is possible to simply 
run the newest migrations to the current database and run the newest 
Redmine on it. It is just a matter now to test the mailing list 
integration plugin into this new Redmine and fix any incompatibilities 
that may have appeared in the API since it was first implemented. I'm 
not sure yet how I can test this mailing list integration plugin but I 
didn't start to try yet so maybe when I start I'll create tickets in the 
project asking for help.

Cheers,
Rodrigo.