When I first browsed through the bugs list, I felt a sense of sorrow for the core team members. Not sure how you manage that list unless you have specialized interfaces which the public doesn't see.
If there's anything we can do to assist in managing/filtering the bugs list, let us know. I am willing to spend time either creating patches or researching/adding remarks on tickets to reduce the time you would need to investigate it. You also see a lot of stuff like below where a decision wasn't made or the patch not applied and is no longer relevant to today's code base: http://dev.rubyonrails.org/ticket/1059 Personally, I prefer the small team of committers as it keeps the project focused on what it is, instead of trying to become all things to all people (like some other language I used to use). I think creating a level above core that filters the "ready to apply" patches/bugs would be a good start to helping out though. Of course, this model requires a certain level of trust which I'm not sure how to "build". Bob Silva http://www.railtie.net/ > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:rails-core- > [EMAIL PROTECTED] On Behalf Of Michael Koziarski > Sent: Wednesday, February 08, 2006 1:39 PM > To: [EMAIL PROTECTED]; rails-core@lists.rubyonrails.org > Subject: Re: [Rails-core] Still trying to get pagination fixed.. STILL > havethis ActiveRecord connection helper thingy pending > > > Rails is completely opensourced under the MIT license as far as I > > know. There shouldn't be proprietary tests. Testing against > > applications is good, but really, that is what unit testing is used > > for in the codebase. > > Amen. > > > Merge monkeys isn't necesarily the best course of action though. Does > > anyone have a better idea? Can we hear the opinion of someone on the > > core team? It's just us talking amogst ourselves and wishful thinking > > until one of you says something. > > Merge monkey's is: > > 1) an insulting name > 2) solving the wrong problem. > > We're looking at ways to get more granular with patches. Currently 2 > line patches which fix a small bug appear in the same queue as massive > feature additions which touch every part of rails. > > Similarly, spelling errors show up alongside complicated bugs relating > to big nested object graphs. > > I think getting more granularity in the queues is the first step. > Any thoughts? > > -- > Cheers > > Koz > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
