Denver Accord #
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.[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.
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.
jonnii
Are there any time lines for this?
Danno
Interesting to get a look into the process on the road to 2.0
Uhm, not sure if you guys know this or not, but you can go above 10 on a version dot number.
1.10.0 wouldn’t necessarily have to be 2.0.0
Nicolas
Concerning the SVN repository for Ruby 1.9, have you though about Sourceforge or other ones (like, say … Rubyforge) ?
pate
Great news! You might want to contact Tim Bray about hardware. He seemed very interested in helping with Ruby and told me that hardware would be one of the easiest ways for him to do this.
murphy
SVN : Love it! Very good decision. Does that mean we get Ruby-Trac, with timeline and tickets and all that? Railsy-like? Mmmh? :)
Thank you, Daigo! We need a Ruby 2 Who-Is-Who somewhere – there are too many names I don’t recognize ^^‘
hgs
We can’t go above 9 on version {major, minor, minorminor} numbers (this has been discussed on Ruby Talk I think, but searching the code will do) because in places they are treated as being explicitly single digits. Doing so will break compatibility.
I’d like to suggest two radical things for this:
(a) Be bold, make the changes to allow higher version numbers. Backport to 1.6. 1.8. (Maybe 1.4? Is anyone using that these days? it used to fit on a floppy, so maybe…) That way backward compatibility issues would be mostly solved. {“I can’t upgrade to 1.6” => “upgrade to latest minorminor version of 1.4”}
(b) Introduce a Version class into the Standard Library, which Gems and similar creatures could use.
The biggest problem with my suggestion is that this is easier to say than do, but if it allows for more fixes and releases between now and Ruby 2.x then it would seem to be valuable work.
why
The Denver Accord.
cilibrar
I am happy to offer the use of my machine as an SVN server over svn+ssh style access permanently, free for ever for your use. I have already emailed Matz the details just email me the keys and final decision top-level module names and I will set you up. Send to cilibrar@gmail.com
Robby Russell
We have space in our racks if Tim Bray wants to send us a server or two for hosting some Ruby stuff. ;-)
Brian M
I mentioned this to Bob at codehaus and he’d be super happy to have codehaus provide svn for ruby as well.
Brian M
I mentioned this to Bob at codehaus and he’d be super happy to have codehaus provide svn for ruby as well.
capn_midnight
Takahashi, Matz, Ko1, Urabe, Ogino and I* Takahashi, Matz, Ko1, Urabe, Ogino and *I Takahashi, Matz, Ko1, Urabe, Ogino and I
ko1
In fact, my (ugly) YARV source code is already open against the world…
bridgeguy
capn_midnight: lay off man, he’s Japanese.
topfunky
I feel so embarrassed. I ate lunch with Takahashi-san for 30 minutes before I realized who I was talking to.
Now I realize that the other person I was sitting next to was Daigo.
We need Ruby luminary collector cards so we can identify our heroes in person!
Oy
CAPN _MIDNIGHT YOUZ a LAMER !
daigo
We have several offers for the svn server, including Tim Bray’s. Thank you all for your kindness. Matz will select the most convenient one. Tim’s will be used for a building and testing platform for Solaris (and it will take some time for Matz to get it.)
I remember you, topfunky.
Danno
hgs, I didn’t know that… still need to get around to reading the Ruby source one day…
If only I wasn’t so damn lazy.