[ruby-core:26102] Re: [ANN] Ruby Developer's Meeting 20091013

Ruby Developer's Meeting: October 13th, 2010
Meeting summary: translated from [ruby-dev:39480]

Participants: matz, ko1, yugui, akr, nobu, usa, naruse
(nobu & usa participated via Skype)

== Release Schedule
=== When will 1.9.2 be released?
* The planned Christmas release date is cancelled [ruby-core:25707]
* "Passing rubyspec" has been added to the requirements for releasing 1.9.2
→ How does this affect the release date?
→ Need to examine the current situation
→ … looks feasible, perhaps?
→ either way, rubyspec will probably be a bottleneck
* everyone should run rubyspec more often, and report any problems found
(problems with ruby or rubspec are welcome)

=== The next preview & feature freeze
* release preview 2 around end of October (motion passed)
* Aim for December feature freeze  (motion passed)

== prime.rb
* timeout issue [ruby-dev:39465]
* Timeout is possible in a multitude of places
* is this an actual problem for anyone?
→ a few cases have been reported in ruby-core, what were they doing?
* is there a need for a feature to declare a critical session with a
block where Timeouts etc are delayed?
→ could pose a problem if, say, ^Cs were suppressed too
→ perhaps explicitly specify what to delay/suppress?
→ will continue to explore possible solutions.

== Big5
* Big5-HKSCS is done
* Big5-UAO is being worked on by Martin, should be done in a few weeks

== Regarding maintainers
* Process for discharging maintainers [ruby-core:25764] [ruby-dev:39372]
* Some people volunteering to become maintainers: [ruby-core:26066]
→ want to accept to volunteers (matz)
→ but want to avoid the situation where new committers from adding
strange, unveiled new features
→ makes sure they know that, as a rule, spec changes must be discussed first
→ however, the libraries they are volunteering to maintain are already
stable enough
→ If the motivation behind volunteering as committers is to be able to
add new features they want, they are likely to be disappointed. This
needs to be considered.
→ there is a tendency for proposals for new features to be ignored
because noone has the authority to reject them
→ how about introducing the concept of committers with limited rights?
→ for the moment, add them as contributors to Redmine, and have them
close/reject tickets, and see how it turns out (motion passed)
→ the final to decision to accept them as committers will be made by matz

== Regarding inclusion of 'ffi' in the stdlib
* what will be using as 'ffi'?
→ libffi
* will we be including the source of libffi?
→ in the current gem, the source is included. If the environment
already has libffi, then that will be used, otherwise the included
source is used.
→ if we include the source, should we always prefer that?
* but first, will we really add it to stdlib?
→ there are problems unsolvable with dl2 (discussed later)
→ ffi uses inline assembly which makes it possible to solve those problems
* Regarding currently unsupported platforms
 * currently works on IA64, code also exists
 → information the website is just out of date?
 * Is Windows supported?
 → supposedly works with VC with a patch
 → works on MinGW
 → the new VC (2010?) doesn't have inline assembler, so it will stop working
 → someone needs to work on supporting it, or else need to get rid of VC
 * Once issues on Windows are solved, it will be possible to add to
stdlib if a maintainer is found

=== The dl2 problem
* it assumes that the types of arguments are consistent, but on ia64,
x86_64 etc, doubles/floats can mix so this assumption doesn't hold
* even if the argument type issue is resolved, it's just a bunch of
bits in memory when we call, so we can't tell what types are expected
at CFunc#call
* plus, information about the arguments isn't available in the CFunc
* in dl1, although there is a precondition that they are on the stack,
arguments come in still holding onto type information, so it's doable
with some hard work
* ff. gets around the issue with inline assembly

== Filepath related changes  win32-unicode-test
* In the work up till kow, found out that there are major difficulties
handling UTF-16LE in ruby itself, so well plan to work via UTF-8
* This means that we need path translation functionality [ruby-dev:39156]
* On unix with default_interenal set, the same problem with path
translation exists
* When using a path (when accessing), we stay on the safe side and
throw an error
* For now, it's GO


--
Leonard Chin