[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]]=20
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=20
> 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=20
> 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=20
> 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