Forum: Ruby-core Towards a better process for changing Ruby

Hey folks,

Recently I've seen a lot of snarky tweets about the process around
changes in Ruby. It seems to me that there *is* a real problem here,
and I feel like this should be discussed here in the open.

I don't have all the details here so I'll try to summarize the current
situation and then you'll have to correct any misunderstandings and
share your perspective.

## State of Ruby

Ruby is mature, and I think it's great that matz has decided to
continue evolving the language without making breaking changes (like
Perl 6 or Python 3).

We have several alternative implementations of Ruby (JRuby and
Rubinius being the most popular one) which tries to keep up-to-date
with the changes that matz approves and are implemented in MRI.

## How does Ruby change?

There are typically two classes of changes:

(1) New functionality. Examples: caller_locations, TracePoint, 
refinements

(2) Spec changes. Examples: Changing #lines to Array.

## Current process

The current process seems something like this:

1. Someone opens a bug report.
2. Discussions.
3. matz acknowledges that it's something we should fix.
4. Discussions.
5. matz approves the whole or parts of the proposed changes.
6. It's implemented pretty quickly in trunk.

## Problems

I think one of the biggest problems is that the 3rd and 5th step often
happens too close to each other (sometimes it's in the same email!).
This means that an issue can go from "new" to "implemented" in just a
few days, and we're missing value feedback from the community.

For functionality changes, it would be very helpful to get feedback
from people working with alternative implementations. There are
certain changes that can be more difficult (or easier) to implement in
other implementations. It would be preferable if we can treat the
other implementations as first-class citizens, and design changes so
they can be implemented outside of MRI too.

Example: Some implementations might have more or less tracing details
available; how does TracePoint handle other events than the one MRI
provides?

I also think that functionality that can be replicated in three
different implementations will be more solid than functionality that's
designed around MRI's current architecture.

For spec changes, it would be helpful if we could actually see the
impact of the changes. There are some people here who works on big
codebases (e.g. Rails) and might know the impact of the changes. And
even if they don't know it off-hand, they might be able to run the
test suites with a patch.

Example: I know for certain that I've depended on #lines being an
Enumerator (e.g. lines.with_index), but I have no idea how common it
is.

If we wish to avoid major changes we need to know the impact of the 
changes.

## My proposed solution

While we're all envy of Python's PEPs, I don't think it will work for 
Ruby.

So I'm only proposing three things:

1. More time between a change is proposed and accepted (let's say, 7 
days).
2. A list of proposed changes (this could just be a Redmine
category/tag; just a way for people to get a big list of all pending
changes).
3. More focus on updating RubySpec. A change shouldn't get accepted if
no-one is able to write specs for it in the 7-day-timeframe.

I think that this should have minimal impact on the current workflow,
and should hopefully give us better feedback from the community.

--

Magnus Holm

What I'd like to see is primarily better communication and release
management. Communication would not just apply to Ruby developers
announcing changes early on but also discussing them with the teams of
the various Ruby implementations. This already happens to a certain
degree but the recent outcry of refinements shows it can be greatly
improved.

One thing I'd like to see is a website of some sort that shows the
various internal aspects of Ruby such as how code such as `*numbers,
number = 10, 20` is handled, how one should implement refinements, etc.
Whenever MRI (or some other Ruby implementation) comes up with a new
feature that affects the syntax, parsing or similar stages this website
would be updated accordingly. In my opinion this would make it a lot
easier to make their own Ruby implementations, code that parses Ruby
code and the likes without having to dig through the C code of MRI.

Release management is another important factor. Ruby 2.0 is closing in
on us and while the version number would imply it potentially contains
non backwards compatible changes (if one were to stick to semantic
versioning) this doesn't seem to be the case. What I, and probably
others fear is that Ruby 2.1 will be a release similar to Ruby 1.9.1.

Yorick

Hello Magnus,

2012/11/29, Magnus Holm <judofyr@gmail.com>:
> ## Current process
>
> The current process seems something like this:
>
> 1. Someone opens a bug report.
> 2. Discussions.
> 3. matz acknowledges that it's something we should fix.
> 4. Discussions.
> 5. matz approves the whole or parts of the proposed changes.
> 6. It's implemented pretty quickly in trunk.

"Implemented" is not the final goal.  It continues:

7. Previews and RCs are released.
8. Someone reports a problem of some features.
9. matz (or a release manager) may reconsider and decide to keep,
change or cancel the features.
10. Official release. The spec is fixed!


> 1. More time between a change is proposed and accepted (let's say, 7 days).

I don't get your point.  Usually, the time between "proposed" and 
"accepted"
is (too) long because matz does not reply so soon.
Did you mean "accepted and implemented"?  It makes sense to me, but as I 
said
above, "implemented" is not "fixed."


Anyway, you want something like a public comment period, don't you?
Then, it is "now" for 2.0.0.


I say again.  Please try 2.0.0-preview and give us your feedback!


We cannot promise to reflect all your feedback to the official release, 
but
we will be happy to consider.  In fact, some feedback, e.g. #7300 and 
#7286,
triggered to revert some changes.

Thanks,

(2012/11/29 20:35), Yorick Peterse wrote:
> One thing I'd like to see is a website of some sort that shows the
> various internal aspects of Ruby such as how code such as `*numbers,
> number = 10, 20` is handled, how one should implement refinements, etc.
> Whenever MRI (or some other Ruby implementation) comes up with a new
> feature that affects the syntax, parsing or similar stages this website
> would be updated accordingly. In my opinion this would make it a lot
> easier to make their own Ruby implementations, code that parses Ruby
> code and the likes without having to dig through the C code of MRI.

see http://svn.ruby-lang.org/repos/ruby/trunk/NEWS

If someone notice something which should be described in NEWS, please 
tell us.

Naruse,

Although this is more useful than the roadmap displayed in Redmine it's
not exactly what I meant. What I think would be interesting is some kind
of search engine that people can use to search for the inner workings of
Ruby. For example, I'd type the query "assigning variables" and I'd get
a list of resources that discuss how Ruby parses variable assignments,
how it deals with splat/expander operators (`foo, *bar = 10, 20` for
example) and so on. These resources would contain also contain various
examples.

This isn't per se something that should be done by the core Ruby team
itself but it should at least be located somewhere on the main website
(or a sub domain) instead of yet another external website (as is the
case with ruby-doc.com and rubydoc.info). It should however be updated
accordingly by the various Ruby teams, I don't have the time and
knowledge to do so on my own.

Yorick

(2012/11/29 21:20), Yorick Peterse wrote:
> itself but it should at least be located somewhere on the main website
> (or a sub domain) instead of yet another external website (as is the
> case with ruby-doc.com and rubydoc.info). It should however be updated
> accordingly by the various Ruby teams, I don't have the time and
> knowledge to do so on my own.

If you wrote it, I can add priviledge to edit wiki of Redmine.
https://bugs.ruby-lang.org/projects/ruby/wiki

> Recently I've seen a lot of snarky tweets about the process around
> changes in Ruby. It seems to me that there *is* a real problem here,
> and I feel like this should be discussed here in the open.


This is a very important and emotionally charged subject, but I feel the 
timing is wrong.

The 2.0.0 release has everyone's focus, and I'm concerned the topic will 
not get the thoughtful, challenging discussion it deserves.

Would it be more productive to postpone this discussion until after the 
2.0.0 release when everyone has had time to step away and introspect for 
a bit?

In addition to Magnus' points, there are other questions and tradeoffs 
we should pragmatically discuss. For example:

* What specifically do we (committers and non-committers) find most 
unproductive about the current process?
* How can we improve the quality of feature requests submitted to 
ruby-core?
* How can we more quickly triage/close issues? Bit rotting issues for 
7,8,9+ months is corrosive on many levels.
* How can we leverage non-committer contributions more effectively?

I'd like to see one of the primary committers (Endoh-san?) re-open this 
discussion soon after the 2.0.0 festivities have ended.

Jon

Endoh-san,

On Thu, Nov 29, 2012 at 1:05 PM, Yusuke Endoh <mame@tsg.ne.jp> wrote:
>> 1. More time between a change is proposed and accepted (let's say, 7 days).
>
> I don't get your point.  Usually, the time between "proposed" and "accepted"
> is (too) long because matz does not reply so soon.
> Did you mean "accepted and implemented"?  It makes sense to me, but as I said
> above, "implemented" is not "fixed."

Oops, it seems I wasn't so clear. By "proposed" I meant that matz
proposed the change (i.e. he made a decision).

And I realize now that by "accepted" I rather mean "considered a part
of Ruby, the language".

I understand (and agree) that it's important to implement changes to
see their full effect, but it's unclear when changes become an
official part of the language. There's a lot of activity on ruby-core
and redmine and it's difficult follow every thread/issue. I feel like
some changes silently become official (without feedback from other
implementers) because it was committed to MRI and "forgotten".

So actually, the timeframe isn't so important I think. It's more
important that we have one big list of "changes that matz want (and
maybe already are in MRI), but hasn't been fully specified/tested".

Hello Magnus,

2012/12/11, Magnus Holm <judofyr@gmail.com>:
> Oops, it seems I wasn't so clear. By "proposed" I meant that matz
> proposed the change (i.e. he made a decision).
>
> And I realize now that by "accepted" I rather mean "considered a part
> of Ruby, the language".

Thank you for the explanation.  I understood.


> it's unclear when changes become an official part of the language.

It depends on what "an official part of the language" is, but my
answer is "a stable release."  You can assume "the change" as an
stable feature that can/will not change drastically nor disappear
suddenly in future minor release.

> It depends on what "an official part of the language" is, but my
> answer is "a stable release."  You can assume "the change" as an
> stable feature that can/will not change drastically nor disappear
> suddenly in future minor release.

I might be mistaken myself but I think Magnus is talking about when the
decision is made to include something in Ruby itself, not when it is
actually released. If this is the case I have to agree that it is not
always very clear when and why (I suspect the language barrier playing a
big role here) something is accepted.

Yorick

2012/12/11 Yorick Peterse <yorickpeterse@gmail.com>:
> I might be mistaken myself but I think Magnus is talking about when the
> decision is made to include something in Ruby itself, not when it is
> actually released.

In a sense, I'm saying that "when the decision is made" == "when it is
released".
I think that there is no other point to suppress matz.
Indeed, matz often alters a decision until it is released.  See 
refinements :-)
But once it is released, matz cannot change the decision (so easily).