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

(2013/04/12 16:40), Charles Oliver Nutter wrote:
> 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.

I introduced CommonRuby as where people discuss about a Ruby Standard,
but I hadn't say anything more than it.
Matz also hadn't.

> 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.

It is your need, isn't it?
Could you force something troublesome to our contributers without concensus?

>> (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.

As marcandre says almost all tickets in Feature tracker will effect JRuby.
If you want to categorize feature tickets, you can set watchers to the ticket,
or I can add some additional fields for feature tickets to mark something.

>> 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.

Where I should create a ticket is a frequent question on OSS projects.
You may know sometimes people make CRuby bug report on Customized version of Redmine,
www.ruby-lang.org, and CommonRuby project though there are descriptions.
This is because Backport trackers is such a cryptic name like Backport 193.

I hesitate to add more complexity here.

> 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.

Saying straight what you want is good nature.
If you want it, the simplest way should be add a new custom field to tickets
which indicate whether the issue affect JRuby or not.

For example
name: affect Ruby Standard
value: true / false / blank

Setting this seems acceptable trouble for us. If it is introduced,
you can track easily both feature and bug in a single place: ruby-trunk project.

>> * 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.

In my experience, normal contributers can't correctly choice whether the 
ticket is bug or feature.
So I felt this is too complicated to apply general users.

Without political correctness at this time I belive adding additional custom field
is most practical way to do all of us want to do.

-- 
NARUSE, Yui  <[e-mail]>