From: "M. Edward (Ed) Borasky" Date: 2007-11-05T07:37:32+09:00 Subject: Re: Ruby's Standard Library could use a lead maintainer James Edward Gray II wrote: > On Nov 4, 2007, at 11:22 AM, Gregory Brown wrote: > >> During the Town Hall meeting with Matz at RubyConf, I asked him >> several questions about Ruby's standard library. I then caught up >> with him later on and talked a bit about maintenance and progress >> issues with the stdlib, and tried to come up with some suggestions. >> >> Basically, Ruby's standard library has some great stuff in it, but >> it's difficult to keep it organized, up to date, and representative of >> what the Ruby community needs. > > This is an interesting issue. It will surely not be easy to address > all concerns, but I think talking about it is healthy. > >> Some issues I'm thinking about that currently exist are: >> >> - It is sometimes hard to contact the maintainers of some of the >> packages > > With TextMate, we do try to keep a current contact email address in > each bundle. These addresses are available to the users and we > encourage them to take their issues there first, but we try to > function as a backup if that plan doesn't work for whatever reason. > > I'm not suggestion Ruby adopt this strategy. I'm just sharing what > I've seen elsewhere. > > I do believe this is a fairly big issue. I mean we currently have a > thread about unbundling YAML and people are concerned by that > possibility. We do need to find someway to at least maintain what's > there. > >> - We have several competing libraries within the standard lib, some >> of them probably can be removed > > I believe the current plan is to remove some of these and I'm glad to > see that step being taken. I think we're making progress here. > >> - There are some libraries that have become defacto standards (such >> as FasterCSV) in the Ruby community, effectively deprecating the >> stdlib which ship with Ruby. > > Some standard libraries do have bugs or performance issues. In some > cases there are libraries that do the same job better or faster. > > Sometimes this is hard to judge though. Sometimes competing libraries > each have their strengths and it's hard to call one better. > > Even in cases where there is a clearly better option, replacing a > standard library is a tricky thing to do. Most people will likely be > angry when Ruby starts breaking their code with regular updates, just > because we wanted to swap out a library. I think Matz tries to be > conservative with the changes for this reason. > > This is a hard problem to solve. > >> My suggestion is that perhaps someone with decent experience with the >> standard library (not me :) could be selected to be a lead developer >> for it. This person wouldn't necessarily be responsible for >> maintaining everything, they'd just be responsible for looking at the >> state of the stdlib as a whole, rather than just the individual >> packages. > > This is a pretty neat idea, though it does sound like a hard job. I'm > having a little bit of a hard time seeing where this person fits into > the current structure. That doesn't mean it's not a good idea, just > that I think the role would need to be pretty well defined to avoid > people getting upset by the person's actions. > >> This person might: >> >> - monitor RCRs and make cases for strong ones to Matz > > The current RCR process seems to be struggling. I think that process > probably needs fixes, before it can be incorporated. > >> - help locate maintainers who have gone missing, or find replacements >> in the event of orphaned code > > Typically, the best way to find a maintainer is to grab someone who > starts submitting patches. Of course, without a maintainer, I think a > lot of current patching efforts are being ignored. We may need to > think about this a little. > >> - Keep an eye on community discussions and give feedback to the core, >> as well as relay information about changes to the stdlib back to the >> community > > We probably need to strengthen the feedback loop all around. This is > the easiest point, but I do think it's valuable. > >> - Act as a decision maker when controversy arises. > > This would be tough. It's hard to know what's the best choice in many > situations that arise with maintenance of the standard library. No > one wants to make a bunch of Ruby developers angry. Clearly > discussion would be needed, at the minimum and Matz probably needs to > be involved on some level, for major decisions. > >> I think that we might benefit a lot from having a person who could do >> this sort of thing to make sure that the stdlib stays up to par with >> the rest of ruby. >> >> What do you all think? > > The above is just my opinions. I could be wrong on any number of things. > > On the whole, the idea is interesting. I'm not sure I completely > understand the role yet, but I'm for anything that makes things easier > for the developers. I think it's at least a great topic of discussion > and I'm glad you brought it up. > > James Edward Gray II > > Well, I think this is one of those, "Oh gosh yes ... that's a *really* great idea ... but *I* just don't have the time" situations. The code base is growing, there are more developers, etc. Somehow all the major open source projects manage to get things done, and I doubt very seriously if Ruby will turn out to be any different in that respect. But you know, considering what a pragmatic bunch of behavior-driven continuous-integration-automation-crazed people Rubyists are (in between Werewolf championships) it wouldn't surprise me one bit if we didn't end up with something that made CPAN look like a slave labor camp. :) Can you tell I'm fading rapidly? :)