Forum: Ruby-core Ruby Implementers Meeting Summary

Hi everyone!

Here is a summary of the implementers meeting.  I am not an expert
summarizer, so you should also visit the wiki for a full log
(http://bugs.ruby-lang.org/projects/ruby/wiki/Devel...).

We'll have another meeting in about one month (depending on Matz's
schedule).

BEGIN

= Proposal of "Ruby Language Team"

== Details

* There are many implementations of Ruby
* Only one Ruby language
* We should form a group to define "Ruby" called Ruby Language Team
* The team consists of representatives from different implementation 
teams
* There will be a new way to propose features
  * Features require Champions
  * Champions belong to the Language Team
  * Champions refine proposals until the Language Team reaches consensus
  * When consensus is reached, proposal is approved
  * Approved proposals are added to RubySpec
  * After addition to RubySpec, the change is now considered "Ruby"
* Implementations are allowed to have experimental features
* Brixen will ensure smooth entry of feature in to RubySpec
* Specs will be in a central repository

== Concerns

* The person proposing the feature should write documentation to
* Brixen shouldn't be single point of failure
* If an implementation can't implement something, is it not "ruby"?
* Is 100% concensus really necessary?
* What about stdlib?
* Is it OK that we communicate in English?

== Results

* Rigid process is not great
* Having an executable spec that can be gradually translated to RubySpec 
is good
* "And I want to make sure as long as I live on this mortal
   state, you need my approval before adding something as official
   Ruby" -- matz
* We should try having more meetings among implementers
* Maybe we should maintain a flag to identify official "Ruby" features?
* Matz wants to remain dictator, but still have participation from 
implemeters.

Aaron and drbrain, thank you for coordinating the meeting!
I've read the discussion log.


Please let me confirm my understanding first.  The current is:

  1. A feature proposal to "Ruby" requires only matz's approval.
  2. "MRI" specifies "Ruby" as a reference implementation.

You suggest changing these points to:

  1. A feature proposal to "Ruby" requires not only matz's approval,
     but also other implementors' approvals.
  2. "MRI" does NOT specify "Ruby", but "RubySpec" does.

Okay?


If I'm correct, I have concerns for each.  Let me state them.
(This is just my personal opinion; you can ignore it if you think
it is unfair to attempt to speak after the meeting)


For part (1), it is still difficult enough to get matz's approval.
Making feature request more difficult will make Ruby's evolution
slower, or even stopped.  I don't think it is a good idea.


For part (2), I'm not against.  I prefer "reference implementation"
style, though.  Anyway, you should first persuade brixen because
this requires RubySpec to change the policy about implementation-
defined behavior.

brixen said to me (in IRC) in the past:

  - The goal of RubySpec is to provide an executable spec for Ruby
    implementors to check their implementation to comply with "Ruby".

  - But, most people think "MRI" behavior as a official feature set
    of "Ruby" even if some of them are actually MRI implementation-
    defined behavior.

  - Thus, he regards "MRI" as "Ruby" ("the Standard" in RubySpec
    terminology) and tries to include all MRI behaviors (including
    implementation-defined one and undefined one) as a "spec".

I thought that his policy was consistent.  (brixen, please correct
me if I'm wrong)

However, if rubyspec now speficies "Ruby", it should accept
implementation-defined, undefined, or unspecified behaviors as is.

There are more MRI implementation-defined behavior than you expect.
For example, AFAIK, "Ruby" does not specify the Float internal
representation, while RubySpec assumes that it is IEEE754.

Such specs that "specifies" implementation-defined behavior, must
be removed from RubySpec.  I'm not sure if brixen is satisfied with
this fact.

> Here is a summary of the implementers meeting.  I am not an expert
> summarizer, so you should also visit the wiki for a full log
> (http://bugs.ruby-lang.org/projects/ruby/wiki/Devel...).


Thank you for making the discussion available. This level of 
transparency is valuable even to we of the users/non-implementors clan.

As a user (CRuby and JRuby on Ubuntu Server, Arch, and Windows 7) I was 
very pleased to see the following:

  [16:19:16] <matz_> I am not going to stop being the dictator, but I 
want you
             guys to participate in the process of improving the 
language
  [16:19:28] <headius> clarifying a point made earlier: 100% consensus 
means
             any no vote acts as veto…so the question is really whether 
matz
             can inject a feature into standard ruby without 100% 
consensus
  ...
  [16:20:49] <matz_> headius, I would keep the privilege, but I promise 
I will
             not use it often

Design-by-committee, or decision-by-committee, or spec-by-committee 
(which, regardless of the words used, is the reality when 100% concensus 
is the process) is bad for users and innovation. It's a very different 
monster than (improved) lightweight collaboration combined with 
leadership that (a) recognizes when meaningful course corrections are 
needed, and (b) takes appropriate and timely action.

I feel much better for Ruby's future (both language and the multiple 
impl's) knowing that spec-by-committee has been clearly rejected. That 
said, I hope the other points that Brian raised in his design process 
blog are not dismissed en masse simply because #7 is the wrong way 
forward.

As a user, I'm also glad to see the back-n-forth happening very publicly 
rather than disappearing into ShadowLand. Or worse, talented devs simply 
abandoning ship because of frustration, or feeling they have no voice, 
or feeling ideas for improvements are always rejected without thoughtful 
consideration.

Jon