[ruby-core:34085] Re: The rights of ruby-core people and Myth of ruby-dev

Is this the right text?

---

Takahashi, Matz, Ko1, Urabe, Ogino and 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.

// Magnus Holm

On Wed, Jan 5, 2011 at 08:29, NARUSE, Yui <[e-mail]> wrote:
> 2011/1/5 Aaron Patterson <[e-mail]>:
>> Why is #ruby:*.jp hosted on irc.ircnet.ne.jp?  Even if English speakers
>> cannot participate in the IRC channel, it would be nice to at least
>> watch.
>
> IRCNet-jp is connected other IRCNet servers.
> So people in non Japan can connect them.
>
> Anyway this is a tracking or visualization problem.
> For example, Denver Accord made at Denver, Colorado in 2006.
> It includes many important decision over 1.8/1.9 branching policy,
> YARV merging, bug trackers,
> migrating to subversion and so on; the most important text of Ruby in 10 years.
> But its discussion is not archived and now the text is also unavailable.
> http://redhanded.hobix.com/inspect/denverAccord.html
>
> All discussion should be available for people in the future.
> Discussion in IRC is not so good, but we need it as much as offline
> meeting, blogs, and twitter.
>
>
> Off topic:
> Some of you write long description to your blog and post the url to
> this list and say "read it".
> Yes, blog is more readable with hilighting with hypertext power.
> But will your host your blog in 2020? 2050? 2100?
> ML is one of the most reliable archive, it is copied over the world.
> So if you think your text is important, please copy the text in the mail.
> (this doesn't prevent to add links)
>
> --
> NARUSE, Yui
> [e-mail]
>
>