skype: matz, nobu

attendee: hone, naruse, ko1, taru, martin, hsbt, zzak, shyouhei, aaron

Release Engineering of patch release


* hsbt のオーダー、ユーザー企業の要望としてはビルドできない、SEGVが起きるというようなcriticalな不具合はすぐに直してリリースしてほしい、そのために hsbt が 2.1 のサブメンテナのような形で関わりたい

 * 二人でメンテナンスするのが良いかどうかは nagachika さんにおまかせする

 * 今日の内容は nagachika さんに hsbt が連絡する

* 例えば hotfix をすぐに出したい

 * すぐに出せるような仕組みは hsbt も頑張る

* 複数人でやるとバックポートが貯まっていた後にcriticalなパッチをバックポートして検証するという時のコストが高くなる

* hotfix モデルにする場合はブランチ設計が必要(hsbt がやりたいと言っていたこと)

* hotfix と stable リリースは区別する必要がない

* まつもとさんは(いやいや)ok>tenny2桁

hsbt: user comapny want to release patch release when it has critical bugs like SEGV. hsbt want to handle it as sub-maintainer.

ko1: heroku also want it.

* up to nagachika about maintaining branch with 2 persons

* hsbt reports to nagachika today’s discusion

* for example immediate hotfix

  * hsbt collabolate to relase hotfix

naruse: current 2.1 branch already has some backports after 2.1.1. how handle them is the issue if we release 2.1.2 immediately. There’s some option (1) revert such commits (2) include them

naruse: if we choose hotfix model (release 2.1.1 with few ciritical fix), we need design new branching model

matz: agree with two digit teeny (with complaint)

matz: no need to distinct hotfix and stable releases

[Feature #9711] Remove test-unit and minitest from stdlib [hsbt]


- hsbt will separate test library for test-all and copy it to test/

- sora_h will decide how handle llib/test/unit

- ryan will decide handle lib/minitest

- we use test/unit (with minitest) for our test-all -> we can solve it easy

- minitest4 conflicts with minitest5/minitest.gem

[Feature #9612] Gemify OpenSSL [zzak]


- ko1 will finish this in 1 month. zzak will check if it’s not done. (June/2014)

[Bug #9613] Warn about unsafe ossl ciphers [zzak]


- it breaks backward compatibility

- if emboss allows the backport of this patch into 2.1 and 2.0, we will merge it.

- it needs to warn and not raise.

[Bug #9671] 2.1 Backport Request #9592 OpenSSL Regression 2.1.0 [hone]


[Misc #9741] Policy for posting security and general announcements [hone]


There was a policy decided.

  1. publically disclosed issue - get consensus on ruby-core/security mailing list members, active ruby branch maintainers (usa & chikanaga)
  2. privately disclosed issue - get consensus on github ( with the w.r-l.o reviewers
  3. everything else - get consensus on github ( with the w.r-l.o reviewers

ruby-core request to announce to w.r-l.o team

two kind of security issues:

known issue and unknown issue

hsbt: known issues: get consensus of github & w.r-l.o reviewers

hsbt: unknown issues: get consensus on ruby-core/security@ members + branch maintainers (usa & chikanaga).

other issues: get consensus on

Status of Branch Maintainer for 2.0.0? [hone]


- see [ruby-core:62051]

When is the next release of maintained Rubies: [hone]


depends on the result of “Release Engineering of patch release.”

Next Meeting: