Summary of ruby-core meeting 2013/12/05

gistfile1.txt

2.1 schedule | http://bugs.ruby-lang.org/versions/27
  rc next week (2013-12-8 - 2013-12-14)
    rc2 only if major issue found in rc1
    make new branch ruby_2_1_0
    code freeze
    bug fix requires maintainer approval
  release on christmas

2.1 maintainer #9215
  undecided
  naruse maintain 2.1 for 2 months after release

semantic versioning #8835
  english: https://gist.github.com/sorah/7803201
  japanese: https://gist.github.com/hsbt/7719305

  we accept hsbt proposal

  starting with 2.1.0
  ruby-{MAJOR}.{MINOR}.{TEENY}
  major: increased when incompatible change (which cant be released in minor)
    "major is for party"
    reserved for major events, and special occasion
  minor: increased every christmas, may be api incompatible
  teeny: security fix, bug fix, which maintains api compatibility
    we increase even more than 10 (such as 2.1.11)
    released every 2-3 months
    matz is concerned about teeny > 10
  patch level: commits since last minor release
    remains p0

  branches
    trunk
    ruby_{MAJOR}_{MINOR}
    keeping using {MAJOR}_{MINOR} branch across TEENY releases
    add tags for each release

  api compatibility
    removing api is incompatible change
    removing (STDIO_READ_DATA_PENDING, etc.) for 2.2
    incompatible change increases MINOR

  ABI
    {MAJOR}.{MINOR}.0
    try to keep ABI compatibility among same {MAJOR}_{MINOR} release
      so TEENY is fixed at 0
    retain ABI compatibility across TEENY releases

  Pros

  Cons
    Changes required to tooling
      * svn
      * backport / merger

  Documentation
    we need to announce that we will be removing the patch level semantics and use {MAJOR}.{MINOR}.{TEENY}


Maintenance Policy for 1.8.7, 1.9.2 #9216

  1.8.7 and 1.9.2 will be supported for security fixes until June 2014
  Committers Terence Lee (hone) and Zachary Scott (zzak) will assume maintainership
  If we someone is willing to help maintain these versions and can commit to a 6 month maintenance period, we can add more committers.
  In the past we have supported vendors who wish to maintain legacy versions
    2009 maintenance of ruby 1.8.6 was transfered to Engine Yard
    They released 1.8.6-p369

Releasing Backports

  As backport maintainer: its ok to release a backport version of ruby for security fixes
  Security releases only
  Ok even after EOL if maintained

Maintenance Policy for 1.9.3 #9217

  1.9.3 maintenance is a commission enterprise of ruby asscociation.
  Maintained for security fixes until march
  Additional 3 month security fix maintenance period may be supported by usa

Maintenance Policy for >= 2.1.0 #9215

  After 2.1.0
    2.0.0:
      normal maintenance until february
      1 year security fix support

  Each MINOR release starting with 2.1.0
    2 years normal maintenance
    3 years security fix support

  A more routine process will improve user expectations

  Each release manager decides the roadmap for their version
    Absolute schedule and maintenace plan is hard

Policy announcements #9219

  I will write:
    maintenance policy announcement for 2.1.0 announcement
    news announcement for www.ruby-lang.org

  mrkn has created:
    bugs.ruby-lang.org/attachments/4091/ruby_maintenance_scheme.pdf

Maintainer appointment and discharge #9218

  If branch maintainer becomes inactive
    nobu can help as global maintainer (patch monster)
    we will decide the next maintainer, ask them for assignment

  Anyone can replace release manager role, should the manager become inactive

  Every issue can escalate to matz
    Maybe we need to replace matz sometime
    We should fire matz

  Asking to declare maintainence period when accepting branch role is rejected

  nagachika:
    I never publish maintenance period for 2.0.0. I thought I can maintain it
    for 2 years in "normal maintenance mode" and then turn into "security only
    maintenance mode".

    now I feel a little hard to keep current pace of activity for maintenance
    for 2.0.0.

  usa may begin maintainence of 2.0.0 in march

GC merits and documentation in README.EXT #8962

  matz ordered koichi to write documentation
  (nobu's children screaming loudly)
  extension authors need a guide to implement WB
  writing extension using WB is difficult
  encouraging use of WB will cause serious problems
  koichi will guide them to write extension without using WB
  we only implement WB internally
  advanced extension authors should refer to internal implementation of WB usage
  direct them to source examples, such as Array which uses WB for implementing their extension
  "its ok to be shady"
  zzak will help

Matsuda commits typo patches
  He is typo monster
  Forgot [DOC] tag in ChangeLog!

Martin Duerst commits too!
  https://github.com/ruby/ruby/commit/737c7d8

Terence joins call:

  Provides feedback on maintainer appointment and discharge process
  People get stuck maintaining something beyond burnout and exhaustion
    Implement process to "pass the torch" while something is still maintained
    We discussed library maintainership
      2 years of normal maintenance is a lot to ask of one person
      A single person should be supported during this process
    Should someone decide to step down
      A process to promote various people to support maintenance
      Include an election process to decide the new maintainer
        ruby-core approval with matz decision
    Should maintainer go inactive
      Discussion takes place to begin election process
    Matz supports adding new committers to support maintenance
    During normal maintenance period, encourages use of old version
    We should support a replacement process
    Encourage other committers to support maintenance

  Feedback on backport versions for security fixes

    downstream vendors support backport versions internally
    we want to externalize this process
    railslts.com
    we have approval to maintain backport versions upstream
      releasing backport versions is ok as maintainers
    We plan to discuss with shyouhei about releasing 1.8.7

Error hiding #7688

  In some cases comparable#== will return false, instead of propagating the exception
  It has improved in some cases, but some exceptions are still hidden
  Matz is undecided
  this change is experimental, so we can try and see if there are any problems
  we cant start experiementing after 2.1 is released

Noone took notes, we had no summary :(
  I rewatched the video and wrote this summary, since most discussion was in English
  The japanese discussion for SemVer was translated on gist thanks to sora

Matsuda will propose gemifying the stdlib at the next meeting