From: Magnus Holm <judofyr@...>
Date: 2012-11-29T17:35:29+09:00
Subject: [ruby-core:50306] 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