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

On Fri, Apr 12, 2013 at 8:08 AM, NARUSE, Yui <[e-mail]> wrote:
> I introduced CommonRuby as where people discuss about a Ruby Standard,
> but I hadn't say anything more than it.
> Matz also hadn't.

It was discussed in meta form during the December IRC meeting. I
believe zenspider suggested a redmine project to house features that
were spec/standard changes.

I certainly appreciate that there's a difference between making
Hash.include? accept a tuple (a recent feature request) and adding
m17n support, but both are spec/standard changes.

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

Certainly not. Nothing changes about the process...what changes is
where implementers need to look for discussions about new features and
feature changes.

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

Well...nearly all features at the Ruby level affect JRuby and all
features at the Ruby-level or C-API-level change the spec/standard of
Ruby.

I hate to bring it up, but what I want is a way to track feature
proposals independent of bug noise in the same way as Python
Enhancement Proposals: http://www.python.org/dev/peps/

Nearly all features, small and large, go through the PEP process and
are discussed in an implementation-neutral forum by all Python
implementers. That's what I want (need).

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

I don't feel like we're adding more complexity. I feel like we're
*reducing* complexity for ruby-core (easier to focus on bugs, since
feature requests will explicitly be directed to CommonRuby) and for
other implementers (single place to look for implementation-affecting
features and feature changes). It also reduces the noise of bugs in
the main redmine projects (old crufty features that never die).

JRuby has a "feature" flag in our older JIRA bug tracker too, but you
wouldn't expect us to have feature changes that affect MRI go in
there, would you? And indeed, if anyone suggests a change to JRuby
that's actually a Ruby feature change, we direct them to ruby-lang's
redmine. I'd like to be able to direct them to CommonRuby, our version
of PEPs.

We need to stop thinking about MRI as "the specification" and move
feature/spec/standard change discussions *out* of the MRI-specific
redmine projects.

> 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

99% of "feature" issues would need to be marked true, so I don't think
this has value.

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

I don't think it's appropriate to track general Ruby feature changes
in ruby-trunk anymore.

Should I suggest we track Ruby feature changes in JRuby's JIRA? Should
we track Ruby feature changes in Rubinius's Github issues? When you
look at it that way it starts to sound rather silly, doesn't it?

Ruby feature changes shouldn't be tracked along with threading issues
or stack overflows in JRuby's issues...so why should general Ruby
feature changes be tracked in the same place as MRI segfaults and
memory leaks?

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

From what I've seen, the majority of feature changes that come into
redmine come in as features from day one. True, many bug reports
become feature changes, but they're usually small changes where it's
hard to tell if they're bugs (even for us implenters) and it's a
trivial matter to punt those over to CommonRuby when it becomes
obvious that they affect all Rubies.

I want to reiterate that I believe this *reduces* complexity for
*everyone*. Users that have a feature idea know exactly where to put
their issue, and they'll be reminded that it affects all Rubies in the
process. ruby-core devs don't need to wade through feature requests to
get to important bugs. Alternative Ruby implementers have a single
place they can go to monitor, propose, and discuss feature changes.
And to the general public, who has been led to believe (by many folks)
that there's no process involved in Ruby's design...it will finally
look like we're collaborating rather than being dragged around by
ruby-core and MRI.

- Charlie