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

I, for one, as a non-implementer would avidly pay attention to CommonRuby as well, since doing so would also give me a good idea of what I can do across all the Ruby implementations out there, and what would most likely be coming into existence in the near and far future on each of them, as well.

This would aid me in my own feature implementations in various projects, aid in determining what mechanics to use *to* implement those features, etc.

I believe, and agree with Charles, that a CommonRuby would have immense value, and not just to Ruby implementers but to coders as well.


-----Original Message-----
From: Charles Oliver Nutter [mailto:[e-mail]] 
Sent: Friday, April 12, 2013 3:41 AM
To: ruby-core
Subject: [ruby-core:54215] Re: Encouraging use of CommonRuby

On Thu, Apr 11, 2013 at 11:25 PM, NARUSE, Yui <[e-mail]> wrote:
> For example original birxen's plan allows only implementers to propose 
> a new feature.

I don't believe CommonRuby fits into any part of Brian's plan because Brian's plan did not involve any existing tools or processes.
CommonRuby was introduced as a way for us to sequester implementation-independent feature changes in a single location where all implementers could discuss them without wondering if they're MRI-specific.

Some voluntary auditing will help here; if I see things I know I'll eventually have to implement, I'll try to recommend they be moved or refiled under CommonRuby.

> (Personally I'm neutral about this restriction though a standard must 
> have at least one major implementation over seeing W3C/RFC standards)

I think the current process works ok, but we need a way to filter out the 80% noise (to implementers) of MRI-specific features. CommonRuby provides a way to do that.

> In addition saying "here is not correct place, make ticket there" is 
> not desired because
> * it prevent creating a ticket by other than us

I don't see that it introduces any such restriction. If a feature request would need to be implemented by any other Ruby to become "common", it should go in CommonRuby. Features that are MRI-specific (RubyVM methods, environment variables, alternative build/configurattion options), should remain on ruby-trunk.

Basically, I'd like to have one-stop-shopping for things I need to consider implementing in JRuby in the future. It would also help to know that visible feature changes are not being accepted as MRI bugs, since that basically means all implementers have to sift through dozens or hundreds of issues that do not directly affect us.

> * it is troublesome for me to say it; I want to simply ignore rubbish 
> feature requests

Indeed! And I think the maintenance of MRI would be easier if we didn't have bikeshedding arguments in ruby-trunk about features that have broader implications than changes to MRI.

> Anyway before encouraging, define CommonRuby and its maintenance rule.

* Any feature that other implementations would need to implement to keep up with "stanard Ruby" in the form of MRI...should go in CommonRuby.
* Rubbish features, one-off repackaging of features, arbitrary API or language changes...those seem like CommonRuby to me. I will watch ComnonRuby more intently than "feature" on ruby-trunk, since so many of those features are about build or env changes specific to MRI.
* No new formal process is involved. We just want o move "feature"
requests that affect all implementations to a more "Common" location.
Very little of the current feature request process would change.

There's a process in building a process :-) I'm happy to continue discussing and refining what we have.

- Charlie