From: Charles Oliver Nutter <headius@...>
Date: 2013-04-12T16:40:38+09:00
Subject: [ruby-core:54215] Re: Encouraging use of CommonRuby

On Thu, Apr 11, 2013 at 11:25 PM, NARUSE, Yui <naruse@airemix.jp> 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