Takahashi, Matz, Ko1, Urabe, Ogino and me talked about a plan of the near future
(hopefully this year) in Ko1’s room at the Sunday night for 4 hours. Here are the
summaries. Matz has agreed them and will post announcements. We are sure that it makes sense for you as well.
1. Prepare a new SVN repository for Ruby 1.9 (called NEW).
The whole of data of the current CVS repository (called MATZ) will be converted to NEW.
Ruby 1.8 is still available in the current CVS.
NOTICE: we have no box to host the new SVN repository. We will be using an interim box
to make a progress. We wish a brand new box right now…
2. Prohibit commits to MATZ
That will be started in a few weeks and last for a month.
3. Merge YARV to the trunk on NEW.
YARV has been implemented in Ko1’s own SVN repository (called KO1), which diverged from
MATZ this April. So, a merging process is a bit tricky.
After making a branch from that point on NEW, he will
make a big patch of his works between April to the latest on KO1, and apply it to NEW.
Then, he (and/or others) will cache up the works between April to the latest
on NEW with many conflicts expected. Finally, the branch will be
renamed to the ‘trunk’. Commits will open again on this head.
That’s the reason of #2, to make this merge process simple and certain.
4. Tasks of Matz and Ko1 before #3
Matz has a try to fix an issue of Array#shift.
Ko1 tries to fix a bug in GC and eliminate ugly parts that he wants to hide
from the world before his works come to the main stage.
If they are not finished the repositories will be reverted to the points where
the bugs were made. So, the merge process will be started on time.
5. Make Ruby 1.8 stable
Ruby 1.8 should be stable both for users and developers. A new feature will no longer be added to Ruby 1.8.[67] or later.
Exceptions are security fixes and version.h. We have 1.8.5 as of now. There is
little space in version numbers to upgrade (1.8.[6-9]). There should be a patch
level to keep on supporting Ruby 1.8.
We recognized that a new category is required in the BTS managed by Urabe.
There are many open cases, including what can not be fixed right now because of
no reproducibles on developers’ hands. Yes, they agree that it may be a bug, and
wait for more information. Those cases interference a debugging process. Let’s
separate them.
We could not think of a good word, which should be simple as a category ID and comprehensible
even for non-native speakers. Fortunately we got a help from two native speakers
who were chatted on a lobby at 1 am. They recommended ‘unverified’.
Thank you. Sorry, I did not write down their names.
Previous Topic
