On 18 Oct 2010, at 12:04, Jon wrote: > > 1) Increased communication and a tweaking of contributor roles. I think > perceptions such as [1] with phrases like "..he looks like ineligible for a > maintainer" and "...the very poor maintenance status of rubygems..." are > warning signs that the issue level has outpaced the project's ability to > respond in a timely manner. This thread's issues and responses also appear > (at least to me) to be warning signs. To me, these warnings indicate a need > to review how RubyGems best utilizes it's contributors skills.
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. I don't even see critical issues being addressed by patches, I mostly see patches for trivial UI changes, or specific mal-usecases. 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. > As a User developer (outsider), I fully appreciate the fact that I don't have > all the facts, but I think ideas like Backup Lead and/or Next Release > Wrangler could help offload Eric when needed, enable much needed contributor > "me time", take better advantage of the contributor horsepower you have, and > minimize perceptions and emails like [1]. In a nutshell, evolution in the > face of RubyGems central role. While the suggestions may sound good on > paper, at the end of the day, you're in the best position to know what's > sustainable by you. This is all very well and good, but who's stepping up? > 2) Increased issue prioritization visibility. What are the key issues > preventing the next release? There's no Issues at > http://github.com/rubygems/rubygems (not really a problem) and the 59 open > issues at [2] (sorted by Priority) don't really indicate which of those are > viewed as "must fix" for the next release. Maybe this list lives somewhere > and I'm missing it? There aren't any "must fix", the critical issues are that of integration points and feature enhancements. They're also quite tied to required feedback to ruby-core which takes some thought. In that regard, other patches for UI and so on are quite acceptable, but their acceptance requires testing time, which is boring and requires diligence in order to not break use cases the original author may not have thought about. > I think a wiki page similar to [3] listing the just the key issues preventing > the *next* RubyGems release is both maintainable and has tremendous benefits > including: > > * Focusing contributor efforts to the highest priority issues. > * Enables easier Drive-by-Contributions for folks having a limited amount of > time to contribute, but wanting to contribute in the high value-add places. > * Better expectation management. For example, if someone posted a bug, > noticed it wasn't considered enough of an issue for the next release (and > felt strongly about it), they could try to be more persuasive as to the risks > if the issue remains unresolved. This is basically all done on the bug tracker right now. Erik Hollensbe persuaded me to start collating some of the issues wrt platform and plugin stuff that I'm working on over on that wiki, which is fine, but the reality is, time spent working on that meant I didn't get the code done for the plugin stuff. I'm hoping I can do that at Rubyconf. 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. 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. I'd really like to know what you're even expecting out of this? Have you tested these expectations? Are they realistic? Drive-by contributions tend to be limited to a single developer, operating on a single platform, running their tests in a single context on a single interpreter. That adds almost as much load as it "saves". > While I have my own favorites I'd like to see fixed, the issue I currently > feel most strongly about is the RubyGems 1.3.7 differences between the one > embedded in 1.9.2-p0 and standalone...both for technical and precedent > reasons. What is done to the Rubygems that's in core is almost inexcusable. Every single developer I've spoken to about what these patches actually do (changing the code base without changing the version, changing the manner in which code is loaded, alter load order semantics in certain cases, etc) they all agree. Sure it'd be nice to educate the whole world, hell I'd like it if I could just dump my and many other peoples brains into a book and force feed it to all new developers. That feeling of mine is arrogant and unacceptable though. The fact is, people either do great work in their patches or they don't. They either understand platforms or they don't and they either look for edge cases or they don't. The edge cases around even "trivial" things like --format-executable are really numerous and somewhat complex social and technical issues. I've seen recommendations going every which way on these topics, and none of them are well suited for a wider variety of user contexts. In order to hit that sweet spot, you've got to practice. Marcus keeps telling me I can use OBS as a kind of CI environment for a lot of *n*x platforms, and that would be great, but I've got to learn OBS too in order to start utilising this. Loads of people seem to come forward with a lot of energy to build the initial spike test of an idea, but always end up disappearing or falling back at the platform issues and such. There is only so much hand-holding available, and until someone steps up who's willing to do that work, your words are merely just documenting the situation in a way that makes everyone slightly uneasy. 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? Are you willing to build up an OBS attachment so we can do cross-package cross-version testing? Would you build a server testing CI to test rubygems.org against older rubygems release versions as well as master? Will you grab the current pull requests and give us a report of ruby versions and major interpreters and platforms in an easy to understand matrix of output showing where it causes failures? Will you then test that against chef and bundler too, to ensure it doesn't break those? And finally what about against plugins, geminstaller, isolate, gem2rpm, etc? Step up please, because that's all that will really help. _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
