Developers Meeting 2012-12-10

This meeting was held on 2012-12-10 at 15:00 Pacific Time at irc://



  • 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)


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


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


  • phlebas (Tim Felgentreff)


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


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"


  • 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


  • 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?


  • 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.


[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:
[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
[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: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
[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
[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
[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
[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:
[15:27:29] because I'd like people to see it
[15:27:42] A list of proposals:
[15:27:42] !
[15:27:49] example proposal:
[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
[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
[15:36:44] Agreed with headius about making sure brixen has enough
[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
[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] 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
[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
[15:50:30] email thread?
[15:50:39] please help us bring this to a close, with your future
[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
[15:51:20] matz_: ok
[15:51:37] Ok, I've heard your oopinion
[15:52:02] The basic point is that you want to participate in the
decision of improving the language
[15:52:13] And it's OK for me
[15:52:23] having champion is fine
[15:52:33] !
[15:53:01] as long as I approve the feature
[15:53:35] but having spec before implementation is too much
restriction I believe
[15:53:52] OK, I want hear from headius now
[15:54:00] !
[15:54:01] headius: ok
[15:54:23] (then tenderlove, enebo, wycats)
[15:54:47] I want to summarize salient points as I see them: 1. a
specific, appointed group of champions from the implementations
through which all features must pass, consensus or not; 2. wiki
for tracking current shape of feature; 3. incoming test suites
probably limitedto specific frameworks (test/unit + rspec +
rubyspec?); 4. end product always to be rubyspecs once feature is
deemed worthy of inclusion
[15:55:09] I think there's a lot of process details we can flesh
out through a separate thread, not needing direct synchronous
[15:55:20] but perhaps we can all agree to that general framework
and take some work offline
[15:55:21] done
[15:55:24] tenderlove: ok
[15:55:31] !
[15:55:35] I agree with headius
[15:55:42] I wanted to address matz concern
[15:55:57] !
[15:56:06] matz_: as part of the language team you have
authority to approve or reject any particular feature
[15:56:30] and people are allowed to implement without a spec,
but those features should not be considered "official" (I would
[15:56:39] !
[15:56:40] !
[15:56:41] done
[15:56:45] shugomaeda: ok
[15:57:02] (then enebo, wycats, evan, brixen, dbussink)
[15:57:03] !
[15:57:09] tenerlove: what's the difference from other members?
you said 100% consensus
[15:57:16] done
[15:57:20] n0kada: ok
[15:57:34] (if you haven't spoken before, you get priority)
[15:57:41] answering dbussink's question (sorry to be late) about
"this happening in english", it'd be less comfortable to me, but
[15:57:54] !
[15:57:55] end
[15:58:01] enebo: ok
[15:58:04] I agree with what headius just said also as a summary
[15:58:12] matz: as experiment do you think you should get 100%
consensus by team before approving it yourself? :)
[15:58:28] <matz
> of course not
[15:58:29] This would be a large change to how things are working now
and I am curious on your thoughts
[15:58:36] ok thank you
[15:58:36] don
[15:58:39] and done
[15:58:52] at the end of the hour I will not accept ! from new
[15:58:56] wycats: ok
[15:59:04] (so if you wish to speak, please ! soon)
[15:59:09] !
[15:59:10] !
[15:59:20] !
[16:00:00] !
[16:00:04] evan tells me wycats walked away
[16:00:10] so, evan: ok
[16:00:12] I am here
[16:00:17] how does evan know I walked away
[16:00:22] lol
[16:00:25] lol
[16:00:26] lol
[16:00:39] oops! sorry, evan, please continue, then wycats
[16:00:40] I am sorry!
[16:00:45] I want to ask a question and defer directly to matz for the
answer: to be clear, will you allow the language team to veto one
of your features? That will mean that MRI may not have that
[16:01:10] I defer to matz_ for the answer directly.
[16:01:22] done
[16:01:25] wycats: ok
[16:01:26] drbrain: ?
[16:01:41] So I want to clarify a few things
[16:01:51] I actually would not expect this to significantly change
how Matz does development
[16:02:04] wait wait, can you wait for matz to answer me?
[16:02:04] soryr.
[16:02:18] and the Team cannot veto an MRI feature
[16:02:29] or that
[16:02:56] matz_: did you see evan's question?
[16:03:31] I wanted to clarify something first
[16:03:38] wycats: please be quick
[16:04:00] This proposal shouldn't significantly alter the way matz
does development
[16:04:10] MRI can add whatever feature it wants
[16:04:20] and nobody can veto Matz adding a feature to MRI
[16:04:27] nor can anyone require a spec before any implementor
adds a feature
[16:04:45] (matz_ doesn't have voice, does he?)
[16:04:54] do I?
[16:04:56] oops
[16:04:57] the goal of this is to have a clear way to explain what
features are generally agreed to by the implementors, so that
people who want to target "Ruby" have a sense of what is supported
[16:05:07] wycats: your time is up
[16:05:09] ok
[16:05:13] my IRC flaked out hard
[16:05:29] matz_: can you respond?
[16:05:57] (then akr_, eregon, sora_h, marcandre. I have pending !s
from brixen and dbussink, too)
[16:06:13] OK, I am not THAT positive about having rigid process
[16:06:51] (reminder, use simple words. Sorry folks. :( /cc
wycats_ )
[16:07:18] But I agree with having executable spec for new spec that
can gradually be translated in to RubySpec
[16:07:53] matz_: specifically, evan wants to know: Will you allow
the language team to veto one of your features?
[16:08:17] And I want to make sure as long as I live on this mortal
state, you need my approval before adding something as official
[16:08:30] lol
[16:08:34] and don't try to kill me ;-)
[16:08:41] lol
[16:08:41] bwahahaa
[16:08:43] hahaha
[16:08:57] :)
[16:08:59] matz_: done?
[16:09:04] almost
[16:09:32] we can improve the process
[16:09:47] And way to communicate each other
[16:10:09] I'd like to have this kind of communication time to time
in the future
[16:10:10] done
[16:10:22] I think many features will be optional. For example, mruby
doesn't have Bignum, so it is optional in the specification if we
approve mruby as Ruby.
[16:10:24] done
[16:10:39] eregon: ok
[16:10:53] I believe 100% consensus from every member of the team is
idealistic, I doubt each member can look at every feature, may the
feature be very well defined (which would be a clear win and a
champion should help). So I think it's more reasonable to just
reach consensus between partipants, have matz approval, and maybe
require at least one approval by implementation for important
[16:11:11] Sorry if I misunderstood.
[16:11:48] What's most needed, I believe, is more discussion on
important features from implementers.
[16:11:49] eregon: done?
[16:11:49] done
[16:11:52] sora_h: ok
[16:12:04] for a question from dbussink, I'm acceptable (sorry for
answering to too far log)
[16:12:11] done
[16:12:17] sora_h: marcandre: ok
[16:12:33] An important point is distinguishing Ruby from CRuby.
Currently distinction is slim. Implementation dependent and
independent tests are mixed in test/
. Feature requests are on
ruby-core, along with CRuby bug reports. I'm not sure we need
separate mailing lists though.
[16:12:33] I wish there was an official way to write all (new)
implementation independent specs & tests. RubySpec is of course
the prime candidate for this.
[16:12:58] An improved feature request / design process would be
great, in particular having an updated description of requests.
[16:13:03] done.
[16:13:05] !
[16:13:26] shugomaeda: since you have only spoken once, please speak
[16:13:31] (then brixen and dbussink) to close
[16:13:37] shugomaeda: … ok
[16:13:39] it's hard for us to maintain both test unit and
rubyspec for all features
[16:14:09] I propose to make a flag for test unit to identify
implementation-defined features
[16:14:15] done
[16:14:19] brixen: ok
[16:14:33] to clarify experimenting, documenting, and rubyspec...
[16:14:41] any implementation can experiment
[16:14:52] before proposing a feature to be "Ruby", it needs docs
and rubyspec
[16:15:08] !
[16:15:12] as for approval, I'm explicitly asking whether matz will
allow the team to override his decision
[16:15:15] zenspider: too late ☹
[16:15:21] in other words, everyone on the team has the same vote
[16:15:30] matz can vote no just like anyone else
[16:15:36] will matz accept this proposal?
[16:15:37] done
[16:15:48] dbussink: ok
[16:16:19] what i would like to point out is that what is
implemented in CRuby but i seen as implementation dependent, often
ends up not being so
[16:16:34] that is because of the place it has in the community
now, that other implementations have to follow
[16:16:54] that is why i think it is very important for features
in that area to be properly specified
[16:17:32] and experiments need to be very explicit, otherwise
reality can catch up on us, independent of whether we decide
something is optional / implementation dependent
[16:17:34] done
[16:17:42] matz_: do you have any closing comments?
[16:17:58] hmm
[16:18:01] (thank you all for participating and making my job as a
moderator easy)
[16:18:18] matz_: perhaps brixen's last question?
[16:19:16] 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] 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:19:47] matz_: i think there are two different situations, you
having to bless every feature
[16:20:05] matz_: and the language team being able to say no to a
feature you propose
[16:20:07] please, we are waiting for matz
[16:20:42] matz_: if you wish to add a feature String#to_ruby, can I
say "no" and it will not be added?
[16:20:49] headius, I would keep the privilege, but I promise I will
not use it often
[16:21:45] matz_: done?
[16:21:47] evan, you have to persuade me, but no just saying no
[16:21:55] !
[16:21:56] that is a satisfactory answer for me
[16:22:01] matz_: keep in mind you can add String#to_ruby to MRI if
you want
[16:22:02] and I am very easy to be persuaded
[16:22:19] but you need to persuade other implementers if you want
THEM to implement
[16:22:40] wycats, yest
[16:23:05] wycats: the point i was trying to make is that is not
always true. it is a very real situations that other
implementations don't really have a choice but to follow
[16:23:07] I think we should now close the meeting
[16:23:16] for the next meeting we will need to have a shorter
topic introduction.
[16:23:16] thanks everyone!
[16:23:17] matz_: your answer is reasonable to me
[16:23:20] I will cut off ! sooner, such as 45 minutes after start
of meeting
[16:23:28] shugomaeda: feel free to speak whenever now
[16:23:57] awesome organization, congrats to drbrain and tenderlove :)
[16:23:59] feel free to remain and discuss whatever you feel like
[16:23:59] I believe only matz should have veto power
[16:24:11] because Ruby is his language
[16:24:29] shugomaeda: i agree and wanted to write the exact same words
[16:24:29] thank you matz and everyone
[16:24:30] I believe he don't do evil things
[16:24:36] drbrain: will the logs continue? I have to leave soon
[16:24:38] thanks everyone!
[16:24:41] brixen: yes
[16:24:43] the major sticking points seem to be: veto power for
anyone, sequence of approval and rubyspecs
[16:24:46] drbrain: thanks
[16:24:52] I'd like to discuss over a longer thread somewhere
[16:24:59] drbrain: thanks for moderating :)
[16:24:59] brixen: I will post meeting logs to the wiki...
[16:25:02] maybe tenderlove could summarize in a ruby-core email
[16:25:08] @ drbrain set topic "last meeting:"