Project

General

Profile

Developers Meeting 2012-12-10

This meeting was held on 2012-12-10 at 15:00 Pacific Time at irc://chat.freenode.net/#ruby-implementers.

Attendees

MRI

  • Eric Hodel - drbrain (moderator)
  • shugo
  • tenderlove (Aaron Patterson)
  • wycats (Yehuda Katz)
  • ko1
  • matz
  • n0kada (nobu)
  • sora_h (sorah)
  • unak (usa)
  • nurse (naruse)
  • emboss (Martin Boßlet)
  • marcandre (Marc-André Lafortune)
  • eregon (Benoit Daloze)
  • akr_
  • eban
  • knu
  • nari
  • wycats
  • tarui (tal)

Rubinius

  • brixen (Brian Ford)
  • dbussink (Dirkjan Bussink)
  • evan (Evan Phoenix)

JRuby

  • headius (Charles Nutter)
  • enebo (Tom Enebo)

MagLev

  • phlebas (Tim Felgentreff)

MacRuby

  • lrz (Laurent)
  • ferrous26 (Mark Rada)
  • jballanc (Joshua Ballanco)

Agenda

We'll keep this meeting to one hour long.

  • Introduction
  • How to improve current process (tenderlove)

Not covered

  • Refinements
    • Experimental feature?
    • Other issues after scope reduction?
  • Ruby 2.0 clarifications
  • Open floor
  • This Meeting
    • Should we do it again?
    • When?
    • How often?
    • How long?

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.

IRC Log

[15:00:27] @ drbrain set topic "Introduction"
[15:00:32]  It's meeting time
[15:00:34]  headius: hi!
[15:00:43]  lrz: hello! ltns!
[15:00:46]  HELLO EVERYONE!
[15:00:48]  MEETINGZ!
[15:00:52]  GOGOGO
[15:01:13]  MERHABA! (that one's for lrz)
[15:01:14]  good morning (on my time)
[15:01:19]  matz_: good morning!
[15:01:24]  matz_: morning!
[15:01:33]  matz_: good night :)
[15:01:35]  hi matz_ evan :)
[15:01:43]  I think we have most everyone here
[15:01:43]  I will just tell everyone "hello" now and cut down the
           greeting noise :)
[15:01:51]  heh
[15:01:56]  if you don't have voice in this channel, please message
           tenderlove or me
[15:01:58]  +1
[15:01:58]  I will just heh at people
[15:02:05]  we'll be following these guidelines:
           http://bugs.ruby-lang.org/projects/ruby/wiki/DevelopersMeetingIRCGuidelines
[15:02:17]  heh
[15:02:38]  we'd like to keep the meeting to an hour
[15:02:45]  ok
[15:02:48]  tenderlove will be introducing topics
[15:03:04]  then we'll give everyone who wishes to speak 2 minutes
           to talk before moving to the next person
[15:03:17]  ebisawa will be provide translation for Japanese speakers
[15:03:31]  hi
[15:03:39]  of course, I'll give extra time to finish what you're
           saying
[15:04:01]  if you don't understand something in English please ask
           ebisawa in #ruby-core
[15:04:08]  ebisawa will only be translating on-demand
[15:04:13]  so please ask her if you do not understand
[15:04:26]  or if you don't know how to say something in English
[15:04:45]  is she ebi-chan?
[15:04:54]  ebisawa no?
[15:04:55]  shugomaeda: yes, it is :-)
[15:04:57]  if you wish to speak during someone else's turn please
           say "!"
[15:05:08]  oh, I see
[15:05:13]  I will be enforcing time limits with voice permisions
[15:05:22]  but I will give you warning
[15:05:31]  sounds very well organized :)
[15:05:35]  lrz: lol
[15:05:36]  tenderlove: would you like to start?
[15:05:39]  Sure
[15:05:46]  Thanks for coming everyone.
[15:05:52]  I'm excited to have all of you here
[15:06:16]  If you check out the list of attendees on the wiki:
[15:06:17] 
           http://bugs.ruby-lang.org/projects/ruby/wiki/DevelopersMeeting20121210
[15:06:38]  You'll see we have participants from every Ruby
           implementation that I can think of
[15:07:13]  So thanks for coming.
[15:07:31]  The first think I want to talk about is improving our
           current communication process
[15:07:42]  we have many Ruby implementations

[15:07:54] @ drbrain set topic "Improving the Ruby design process"

[15:08:09]  but the important thing is that we're all
           implementing the same language, Ruby
[15:08:30]  the Ruby language is our common ground
[15:08:48]  we implement the same language, so I think that we
           should be on the same team
[15:09:05]  working for the same goals
[15:09:10]  but doing it together
[15:09:36]  For example, when someone says "What is Ruby?", it's
           something that *we* need to answer
[15:09:41]  not just MRI team, but all of us
[15:09:58]  so I'd like to propose an experiment
[15:10:48]  I'd like to propose a Ruby Language Team
[15:11:16]  an experiment to give implementers equal voice, and a
           vehicle for driving communication among implementers
[15:11:54]  Of course this is a different style of development
           than what we do today
[15:12:45]  MRI is just an implementation
[15:12:58]  one that has a strong voice in driving forward the
           Ruby specification
[15:13:25]  but like other implementations, it should be able to
           experiment with new features without defining "Ruby"
[15:13:46]  we need a way to describe the difference between MRI
           and "Ruby"
[15:14:53]  a Language Team allows MRI to separate experimental
           features from features that matz_ indends to propose as new
           features to "Ruby"
[15:15:05]  the same method can be used for any implementor to
           propose new features
[15:15:19]  for example, shugomaeda worked on refinements
[15:15:28]  and Rubinius is interested in standardizing channels
           and actors
[15:15:52]  we need a place for everyone to discuss the future of
           "Ruby" abstracted from the details of the experimental
           implementations that people are working on
[15:16:33]  this is where the Ruby Language Team comes in
[15:16:44]  we can use a framework for defining new features
[15:17:09]  Someone proposes a feature to the mailing list
[15:17:19]  (this could be anyone)
[15:18:05]  The person who wants the change must find someone on
           the Ruby Language Team to champion this feature
[15:19:11]  The champion, is someone who is interested in the
           feature enough to put in the work on designing the feature
[15:19:29]  it's that person's responsibility to work with the
           rest of the team to define the feature
[15:19:40]  for trivial features, this means one person, for
           non-trivial, maybe several people
[15:19:49]  but in no way is it "design by committee"
[15:20:05]  once the champion can refine the feature such that
           the group reaches consensus
[15:21:09]  sorry, when the feature is proposed, we keep it in a
           wiki
[15:21:31]  the important thing about this is that at any point,
           an implementer can look at the proposal for it's current status
[15:21:40]  the champions refine the feature based on feedback
           from the group and bring it back on the agenda for another meeting
[15:21:54]  eventually the team reaches consenus
[15:22:05]  and it's proposed for a future version of Ruby
[15:22:16]  at this point, brixen will turn the feature into
           well-define RubySpecs
[15:22:25]  the spec will be brought back to the Team to make
           sure it matches what everyone agreed to
[15:22:29]  !
[15:22:37]  once it is in the specification, implementors should
           implement
[15:22:41]  *all implementors
[15:23:04]  if people do not want to implement, they should
           object earlier
[15:23:17]  the process of getting consensus is the process of
           determining that all implementors are comfortable with the feature
[15:23:19]  done
[15:23:22]  sorry I took so long
[15:23:22]  brixen: your turn
[15:23:23]  :(
[15:23:30]  hello
[15:23:36]  thanks all for attending
[15:23:52]  I just wanted a quick clarification on "brixxen will turn
           feature into RubySpecs"
[15:24:00]  er brixen rather
[15:24:19]  in my rubyconf proposal, I asked for the person proposing
           the feature to write documentation
[15:24:22]  and then rubyspecs
[15:24:27]  which I can certainly help with
[15:24:39]  but my question would be: why is that not the proposed
           process?
[15:25:07]  brixen: when done, please say "done" or "end"
[15:25:12]  yes, sorry
[15:25:15]  !
[15:25:16]  done
[15:25:24]  I don't want to hand the floor to someone while you're
           still speaking :D
[15:25:28]  wycats: ok
[15:25:44]  RubySpec would be considered the endpoint of the proposal
           process.
[15:26:24]  Proposals themselves could use the language of RubySpec
           to provide examples, but brixen is the one with a coherent
           understanding of how to integrate a new feature into the wider
           RubySpec project
[15:27:02]  !
[15:27:05]  So brixen would be responsible for making sure that any
           new features that got consensus would be integrated smoothly into
           RubySpec in a way that he felt comfortable with as the
           "specification author"
[15:27:10]  done
[15:27:13]  tenderlove: ok
[15:27:24]  So I put together an example here:
           https://github.com/tenderlove/ruby/wiki/The-Ruby-Programming-Language
[15:27:29]  because I'd like people to see it
[15:27:42]  A list of proposals:
           https://github.com/tenderlove/ruby/wiki/Straw-Man-Proposals
[15:27:42]  !
[15:27:49]  example proposal:
           https://github.com/tenderlove/ruby/wiki/IO.readlines-should-use-keyword-arguments
[15:27:54]  done
[15:27:57]  evan: ok
[15:28:28]  The question of RubySpec usage is one of complete test for
           a feature
[15:28:59]  if a champion provides a complete test suite for a feature
           in any form, I believe that will be succifient
[15:29:18]  !
[15:29:30]  The big worry of having one person (brixen) write RubySpec
           after the fact is the act of having to discover all the features
           and edge cases after the fact
[15:29:59]  if they're all documented in tests by the champion, a
           process of converting them to RubySpec could be by easily by a
           number of people
[15:30:10]  !
[15:30:14]  so the issue is really the completeness of a test suite
           available for a feature
[15:30:15]  evan: please wrap up
[15:30:15]  done
[15:30:25]  I will go with lrz first, then wycats
[15:30:27]  lrz: ok
[15:30:50]  ok, what if a feature gets accepted by the language team,
           but cannot be implemented in a specific implementation of the
           language
[15:30:56]  (for ex. if it does not make sense)
[15:31:08]  does that implementation cannot call itself "ruby"?
[15:31:09]  done
[15:31:15]  wycats: ok
[15:31:22]  !
[15:31:33]  lrz: the implementation should object to the feature when
           it is raised, which will mean it does not reach consensus
[15:31:45]  evan: i think it makes sense to have a well-defined
           feature, including with tests
[15:31:59]  !
[15:32:07]  so every implementation has veto power on all features...
[15:32:08]  but we should avoid getting overly concerned about
           whether the tests are in "RubySpec style"
[15:32:09]  done
[15:32:19]  wait
[15:32:24]  wycats: continue
[15:32:54]  lrz: I would not use the term "veto power". It is a
           consensus process. Implementations should avoid objecting to
           features they have minor disagreements with.
[15:32:55]  done
[15:33:16]  enebo: ok
[15:33:18]  I have 2 questions: 1) What is concensus (really 100%)?
           2) How fine-grained is the scope of enhancement?
[15:33:41]  !
[15:33:42]  2 is particularly troubling to me since I could see this
           almost replacing redmine
[15:33:45]  done
[15:33:48]  headius: ok
[15:33:54]  ok...neato
[15:34:11]  so first off, I suppose the idea so far…especially the
           idea that there's a central authority for specs
[15:34:22]  that may be brixen alone but probably would be better as
           a blessed team that can help implement
[15:34:41]  given a complete set of incoming tests, or a really
           well-written english specification, I think that's going to
           produce the cleanest rubyspec results
[15:35:09]  !
[15:35:11]  my concern is making sure brixen is not the sole
           responsible party, which means we need a way to ensure incoming
           features have enough coverage via test cases or english spec
           before hand-off
[15:35:12]  done
[15:35:20]  wycats: ok
[15:35:26]  (sole responsible party as in brixen shouldn't have to
           do everything alone)
[15:35:59]  enebo: consensus means "100%", but a good consensus
           process is one where people aim to reach consensus, not focus on
           exercising their veto
[15:36:16]  in terms of Redmine, I'd expect it to become a bug
           tracker for the MRI implementation, rather than a place to discuss
           new features
[15:36:26]  !
[15:36:30]  it would still be an appropriate place to discuss MRI
           implementation of new features or patches containing experimental
           features
[15:36:44]  Agreed with headius about making sure brixen has enough
           help
[15:36:57]  however, I think it's important to have a single "spec
           editor" with a sense of the full aesthetics
[15:36:57]  done
[15:37:10]  !
[15:37:15]  tenderlove: ok
[15:37:33]  !
[15:38:00]  lol, I think wycats covered what I wanted to say.
           Though, I'd like to hear from matz_ ;-)
[15:38:01]  !
[15:38:01]  done
[15:38:08]  evan: ok
[15:38:26]  A champion may wish to introduce a platform feature
[15:38:33]  thats not capable of being implemented everywhere
[15:38:40]  an example would be fork
[15:38:48]  !
[15:38:52]  these feature should be consider the exception rather than
           the rule
[15:39:03]  and would likely be explained to be optional
[15:39:04]  done
[15:39:07]  emboss: ok (brixen will follow since emboss hasn't
           spoken)
[15:39:17]  Two quick questions: 1. How would the process extend to
           extensions that are part of stdlib (net/http, openssl...) and 2.
           What should happen in the case of let's say OpenSSL where there is
           no RubySpec yet? Write some asap?
[15:39:22]  Done
[15:39:25]  brixen: ok
[15:39:47]  I want to emphasize that my proposal calls for a complete
           documentation and rubyspec before voting to implement
[15:39:55]  !
[15:40:01]  and I'd like there to be core Ruby features and
           standardized optional Ruby features
[15:40:03]  done
[15:40:04]  zenspider: ok
[15:40:15]  Redmine already has multiple projects. It would be a
           good place to make one specifically for talking about proposals.
           We need something permanent and trackable as we've had too much
           stuff fall through the cracks when it is just email and IRC.
[15:41:10]  rubyspec shouldn't be a requirement before voting to
           implement. ANY form of specification (unit test, english,
           whatever) should be required
[15:41:11]  done
[15:41:13]  matz_: we would like your opinion
[15:41:18]  !
[15:41:20]  <3<3<3
[15:41:40]  I'm listening
[15:41:48]  :P
[15:41:51]  ok, then dbussink: ok
[15:41:51]  !
[15:42:14]  drbrain: ok to who first?
[15:42:21]  dbussink: you
[15:42:25]  matz is listening still
[15:43:12]  ok, i would also like to request feedback from a larger
           group of the mri team. A lot of development is happening in japan
           and i feel that this would not work well if they will not support
           it too
[15:43:32]  what i'm asking is whether there are objections there,
           maybe language or process wise
[15:43:53]  are people comfortable with the idea and also with
           aspects such as this happening in english
[15:43:55]  done
[15:44:25]  _ko2, nurse, n0kada: if you have a comment, please bring
           it up
[15:44:35]  or other .jp ruby developer
[15:44:39]  enebo: ok
[15:44:55]  I am still fairly concerned from moving from a master
           surgeon sort of design (or Matz-driven design) to one of 100%
[15:45:03]  100% consensus
[15:45:12]  !
[15:45:47]  I am not always in agreement with Matz and would like a
           process for new features but JVM had 100% consensus for features
           and it ended up giving us a horrible generics implementation
[15:46:14]  I like the idea in general but the 100% consensus bit rubs
           me
[15:46:15]  done
[15:46:18]  !
[15:46:25]  wycats: ok, then jballanc and tenderlove
[15:46:34]  !!
[15:46:49]  No implementation would be required to wait for approval
           before beginning implementation
[15:47:04]  I would expect matz_ to continue working much the same
           way he has worked so far -- implementing features experimentally
[15:47:18]  but now, he would bring those proposals to a wider group
           to get feedback and try to reach implementor consensus
[15:47:30]  re: optional features, that's totally fine, of course
[15:47:39]  for example Function#toString in JavaScript is optional
[15:47:45]  but if implemented, it has a well-defined specification
[15:47:49]  and finally
[15:47:54]  the endpoint of the process would be something like
[15:48:02]  1) general consensus about the proposal
[15:48:09]  2) specification language by brixen et al
[15:48:18]  3) consensus about the actual specification language
[15:48:28]  it would be totally fine if people wanted to wait for
           spec language before implementing
[15:48:36]  done
[15:48:41]  -!
[15:48:49]  jballanc: ok
[15:48:58]  I would like to +1 part of what brixen said (about
           standardized optional features) and suggest the SRFI (Scheme
           Request for Implementation) model might be good to follow
[15:49:26]  in particular, that the standardized optional features
           are tied to a mechanism to include them at runtime
[15:49:43]  i.e. similar to tail-calls in 1.9 and (maybe?)
           refinements in 2.0
[15:49:49]  done
[15:49:55]  !
[15:49:59]  we have ten minutes left in our scheduled hour
[15:50:14]  I'm unsure how close we are to wrapping up this agenda
           item though.
[15:50:22]  I suggest we defer the remaining items to a future
           meeting
[15:50:30]  email thread?
[15:50:39]  please help us bring this to a close, with your future
           comments
[15:50:47]  I would still like to hear from matz though
[15:50:57]  I think the existence of a proposal process is a
           bootstrap for the remaining agenda items
[15:51:00]  or any other japanese developer
[15:51:16]  !
[15:51:17]  ditto... we need sign on by ruby-core or this is all a
           wash
[15:51:20]

Like0