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

(2013/04/13 0:56), Charles Oliver Nutter wrote:
> 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).

If you propose a process based on PEP, it should be considered.
(I sometimes wish there were a comprehensive document about added new feature like PEP
even if I don't want to write it)

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

Usually I see only bugs by filtering tracker.
So I feel you neglect filtering or have another reason which you hadn't say.

> (old crufty features that never die).

I had considered moving such features to CommonRuby.
For example syntax related one should be moved even if you and I think it is crafty on your policy.

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

CRuby to JRuby and JRuby to CRuby is different, it's not a good example.

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

I think there's no practical difference though there's political difference.
You regard such political difference as important?

Note that I don't hate such politics.
What I want to say is such politics is prior to another elements,
so you must say such requirements first.

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

If you think 99% of "feature" issues would need to be marked true,
it conflicts with following your words in [ruby-core:54214].
I want to say "please filtering for Feature and be patient 1%".

-----
> Can't you filter on the subject of the message for "Feature"?
>
> If so, I would simply merge Common Ruby into trunk

I think there's a very clear line between MRI features and "Ruby"
features. I need to know the latter in order to make JRuby as
compatible as possible. I don't really care about the former.
-----

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

If I'm a follower of JRuby, it will be YES.
If I'm a follower of Rubinius, it will be YES.
I'm tracking IronRuby.

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

I really think they are different places if they can divide with machine.
If you don't think so, I think it is not practical reason but political reason.
Therefore you must say it without reason, say it as premise/precondition/requirement.
We'll design CommonRuby process based on it.

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

I just noticed, you intended bundled libraries are also discussed in CommonRuby?

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