Takahashi, Matz, Ko1, Urabe, Ogino and
me I 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 catch 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. 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.
6. A new category to the BTS
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.
Urabe will also add English views to the BTS.