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.
on 2012-12-11 02:49
on 2012-12-11 14:34
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.
on 2012-12-12 18:51
> 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