On 18 Oct 2010, at 16:34, Jon wrote: >> Sure, it'd be nice if we had someone paid to work on this full time, but >> that's not the case. I don't see anyone stepping forward, all I see are >> complaints about the fact that people are saying they're busy. > > Perhaps an existing contributor has extra cycles to be Next Release Wrangler > if they saw *exactly* what should be addressed for the next release and could > determine whether they can make the commitment. That's not to say this person > is responsible for implementing all the fixes. > > Odds are probably against it though, but I see value in explicitly stating > the v.next Fix List and seeing where things go.
I'm trying to understand what you're getting at here. It seems to me that you're skipping around not actually saying that you want a release "next week" or "next month" and you want someone you can call out if this doesn't happen. I'm really interested to know what it is that needs direct attention to you, and why this pressure is being applied and you want to set some target in stone. What's the value? Where is this coming from? >> There is a great history of real bugs in the rubyforge backlog, and quite a >> few patches that need someone to read, think, and rewrite. >> ....[SNIP].... >> There aren't any "must fix", the critical issues are that of integration >> points and feature enhancements. > > Throw up a target by explicitly prioritizing the big issues in the backlog. > What in your view are the 3-5 bugs currently in the rubyforge tracker that, > if fixed, would cause you to green light a 1.3.8? I'm not really worried about 1.3.8, I'm actually more looking toward something that would be a 1.4 with the changes I want to make. Plugin API changes have been documented both on the ML and in the Wiki entries. Longer term changes to get platform integration stuff done, I'm looking at a February target. I've scheduled it that far out so that I have the chance to schedule some time for this, even if it requires me booking time off work to really focus on it. I'd rather not do that, but I may need to. I'm also still researching as time allows, what is required by each platform, there are lots of steps to this task, and those require lots of writing to other people if someone else wants to take it on. I'm not going to waste those hours unless someone is actually realistically putting at least 20 or so hours on the table (for someone with real experience, more for someone who has less - which would also take more of my time away from other things). >> What you're asking is that I write down all my thoughts in great detail, >> which takes much longer than writing the code or doing the due dilligence >> and research, basically multiplying my workload by 4x. > > No, I only want to know the "official" top issues to resolve for a 1.3.8 > release. 1.3.8 would be a bugfix release. Most critical bugs have been tackled in master already, but there are more outstanding in the tracker. I'd try to clear the tracker next time I sit down to do maintenance work, or at least get through a major chunk of it. >> I'd agree with this if it would result in patches and better thinking from >> people, indeed that's what I hoped when I put the details up on the wiki at >> Eriks request. Thus far, that's proven to be a complete pipe dream. > > Unfortunately, I have to agree with you on this. That said, there are often > non-immediate serendipities (?) that occur that always surprise me. For > example, as part of the RubyInstaller project, the effort to make it easier > for Windows users to build native extensions has recently led someone to work > on porting Redis to Windows -> > http://groups.google.com/group/rubyinstaller/browse_thread/thread/ba6bac3df60fefdb I really don't see how this applies. The statement is really along the lines of "doing anything could cause anything else to happen", that's great, but it's not a target. >> You want more contributors, but are you going to step up? Are you willing to >> pay for a CI system that has a VM for a few major linux platforms, BSD, OSX >> and Windows? >> >> ....[SNIP].... >> >> Step up please, because that's all that will really help. > > Sadly, I don't have the time to commit to doing any of these in a > sustainable, value-add manner so I'm not going to lie to you, say I might, > jump in and then disappear. Then I think this discussion needs to end, because it too is dissolving available time. > What I currently have time to do is maintaining wiki documentation that might > jump start others to help with these efforts and offer to help offload you on > documentation stuff. Your expertise and limited time is best used solving > the hard issues. I'm thinking of two key pages: Next Release Showstoppers > (short-n-sweet listing and links back to the current 3-5 top rubyforge bugs), > and RubyGems Project Needs (CI, OBS, etc). You want to write documentation, but you don't have the info in your head. If you are willing to take a mass flood of info over skype, research it until you can communicate it more clearly, then contact me off list and I will rant at you for an hour or so. If you believe this will be useful, and you have the time to do it, fantastic, please do so. I'd encourage any contributions in that way. Alternatively, if you want less stressful documentation to do, the articles on docs.rubygems.org still need updating and improving, so please, have at it. One section that immediately comes to mind is the section on gemspecs. > With the project needs clearly identified, shopping for project sponsors, > starting a Pledgie for financing CI/VM needs, etc makes more sense. Most of us (from what I can gather, this is at least true for myself), don't need money, we need time. Sponsorship for rubygems is unlikely to pay for someone to go part time or full time. > I admit these sound trivially underwhelming given all that you've identified, > but if this micro-step-up could add any value, I'll do it. Eric is really in control of this, being the current maintenance head, and the longest standing active committer on the project (afaik). In light of that, I would say that this is his call, or if he can't do so, then really you want to talk to RubyCentral to push this through. _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
