Kevin Clark
2006-Feb-07 07:04 UTC
Still trying to get pagination fixed.. STILL have this ActiveRecord connection helper thingy pending
Hi guys. Apparently my complaints about lack of feedback didn''t get any notice. Funny that. Anyway, tests which isolate the pagination error have been written for a long time. I''m still waiting on feedback or commital of the ActiveRecord Helper thingy.. I don''t think it''ll work as a super class of Test::Unit::TestCase (see previous email). Whatever. I''m disillusioned. I''d love to get this stuff fixed, but rails-core doesn''t seem to scale with regards to handling patches. I''m sorry if I sound ungrateful. I''m really not. I''m just tired of not being able to fix things. No, I don''t want to make it a plugin. There is already a plugin to fix the bug. *sigh* Kev
Steve Purcell
2006-Feb-07 11:31 UTC
Re: Still trying to get pagination fixed.. STILL have this ActiveRecord connection helper thingy pending
On Tuesday 07 February 2006 08:04, Kevin Clark wrote:> > Whatever. I''m disillusioned. > > I''d love to get this stuff fixed, but rails-core doesn''t seem to scale > with regards to handling patches. > > I''m sorry if I sound ungrateful. I''m really not. I''m just tired of not > being able to fix things.It''s not clear to me whether the bottleneck is the time the core developers have available for reviewing patches, or simply the time required to merge acceptable patches. If the latter is the problem, as I suspect it is, perhaps the core team would be willing to solicit one or more non-core volunteers to act as "merge monkeys". The volunteers'' task would be to fix up, apply and close patches signed off in principle by the core team. Any thoughts? -Steve -- Steve Purcell Sanity Inc. - Software for a saner world http://www.sanityinc.com
Kevin Clark
2006-Feb-07 18:45 UTC
Re: Still trying to get pagination fixed.. STILL have this ActiveRecord connection helper thingy pending
> It''s not clear to me whether the bottleneck is the time the core developers > have available for reviewing patches, or simply the time required to merge > acceptable patches. > > If the latter is the problem, as I suspect it is, perhaps the core team > would be willing to solicit one or more non-core volunteers to act as > "merge monkeys". The volunteers'' task would be to fix up, apply and close > patches signed off in principle by the core team. > > Any thoughts? > > -SteveAnother layer could help I think.
Julian ''Julik'' Tarkhanov
2006-Feb-08 20:25 UTC
Re: Still trying to get pagination fixed.. STILL have this ActiveRecord connection helper thingy pending
On 7-feb-2006, at 12:31, Steve Purcell wrote:> On Tuesday 07 February 2006 08:04, Kevin Clark wrote: >> >> Whatever. I''m disillusioned. >> >> I''d love to get this stuff fixed, but rails-core doesn''t seem to >> scale >> with regards to handling patches. >> >> I''m sorry if I sound ungrateful. I''m really not. I''m just tired of >> not >> being able to fix things. > > It''s not clear to me whether the bottleneck is the time the core > developers > have available for reviewing patches, or simply the time required > to merge > acceptable patches. > > If the latter is the problem, as I suspect it is, perhaps the core > team > would be willing to solicit one or more non-core volunteers to act as > "merge monkeys". The volunteers'' task would be to fix up, apply > and close > patches signed off in principle by the core team. > > Any thoughts?Which would include giving the "monkeys" complete access to the 37s application code (because I think THIS is what all the patches get tested against, I think). The problem is that there are tests which are not included in Rails and are effectively proprietary, but 37s (being the core maintainers of the framework) have the privilege of verifying patches against their own applications before the patches are rolled out. Not to offend anyone - just a thought. -- Julian ''Julik'' Tarkhanov me at julik.nl
Rick Olson
2006-Feb-08 20:53 UTC
Re: Still trying to get pagination fixed.. STILL have this ActiveRecord connection helper thingy pending
> Which would include giving the "monkeys" complete access to the 37s > application code (because I think THIS is what all the patches get > tested against, I think). The problem is that there are tests which > are not included in Rails and are effectively proprietary, but 37s > (being the core maintainers of the framework) have the privilege of > verifying patches against their own applications before the patches > are rolled out. > > Not to offend anyone - just a thought.I test patches against my own applications as well. Everyone should do the same. Sometimes I have my own proprietary code/tests that I extract out as patches to be submitted. I''m not sure I see the problem. -- Rick Olson http://techno-weenie.net
Kevin Clark
2006-Feb-08 21:15 UTC
Re: Still trying to get pagination fixed.. STILL have this ActiveRecord connection helper thingy pending
On 2/8/06, Rick Olson <technoweenie@gmail.com> wrote:> > Which would include giving the "monkeys" complete access to the 37s > > application code (because I think THIS is what all the patches get > > tested against, I think). The problem is that there are tests which > > are not included in Rails and are effectively proprietary, but 37s > > (being the core maintainers of the framework) have the privilege of > > verifying patches against their own applications before the patches > > are rolled out. > > > > Not to offend anyone - just a thought.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. 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. Kev
Michael Koziarski
2006-Feb-08 21:30 UTC
Re: Still trying to get pagination fixed.. STILL have this ActiveRecord connection helper thingy pending
> Which would include giving the "monkeys" complete access to the 37s > application code (because I think THIS is what all the patches get > tested against, I think). The problem is that there are tests which > are not included in Rails and are effectively proprietary, but 37s > (being the core maintainers of the framework) have the privilege of > verifying patches against their own applications before the patches > are rolled out.> Not to offend anyone - just a thought.While 37 signals (and joyent, odeo, shopify, fluxiom etc.) have applications to support, the core team also has a commitment to rails itself. Part of that commitment is making sure that the tests in rails accurately reflect our own usage. If I find a change has broken something in joyent, I update the tests bundled with rails to cover that usage, so it doesn''t happen again. David, Jamis, Marcel and Sam have the same responsibility, and do the same thing! If we commit something which passes the rails tests and basecamp breaks. Then sorry guys, that''s Basecamp''s problem ;). 2/3rds of the Rails core team work for companies other than 37 signals. The problem at present is that most of us are in the crunch phase of our applications, and we''ve fallen *way* behind on the patch queue. We realise that, it''s not acceptable, and we''re working to regain momentum. -- Cheers Koz
Michael Koziarski
2006-Feb-08 21:38 UTC
Re: Still trying to get pagination fixed.. STILL have this 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
Bob Silva
2006-Feb-09 01:42 UTC
RE: Still trying to get pagination fixed.. STILL havethis ActiveRecord connection helper thingy pending
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: rails-core-bounces@lists.rubyonrails.org [mailto:rails-core- > bounces@lists.rubyonrails.org] On Behalf Of Michael Koziarski > Sent: Wednesday, February 08, 2006 1:39 PM > To: k1clark@ucsd.edu; 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
Kyle Maxwell
2006-Feb-09 02:01 UTC
Re: Still trying to get pagination fixed.. STILL havethis ActiveRecord connection helper thingy pending
On 2/8/06, Bob Silva <me@bobsilva.com> wrote:> 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/Actually, that extra layer already exists. There is already the ability for anonymous users to add keywords to tickets. All we have to do, as the community, is agree on the meaning of keywords that we want to apply to tickets. i.e: r2g: ready to go micro: a really small fix typo, docs, etc As the core team members start to realize that things are being tagged by the community, they'll start searching on the tags. If you want to contribute by tagging up a bunch of patches, I would think it would be appreciated. -- Kyle Maxwell Chief Technologist E Factor Media // FN Interactive kyle@efactormedia.com 1-866-263-3261 _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Bob Silva
2006-Feb-09 03:12 UTC
RE: Still trying to get pagination fixed.. STILLhavethis ActiveRecord connection helper thingy pending
r2g and micro are pretty subjective though so I don''t see how that helps the core members any. They still have to review the patch, write and run unit tests and any additional testing they so desire, assuming they can find the time to do it. I don''t believe the community in general can fulfill this role but you don''t need commit rights to do it either. The problem will only compound itself as the popularity of Rails grows. Bob Silva http://www.railtie.net/> -----Original Message----- > From: rails-core-bounces@lists.rubyonrails.org [mailto:rails-core- > bounces@lists.rubyonrails.org] On Behalf Of Kyle Maxwell > Sent: Wednesday, February 08, 2006 6:02 PM > To: rails-core@lists.rubyonrails.org > Subject: Re: [Rails-core] Still trying to get pagination fixed.. > STILLhavethis ActiveRecord connection helper thingy pending > > On 2/8/06, Bob Silva <me@bobsilva.com> wrote: > > 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/ > > Actually, that extra layer already exists. There is already the > ability for anonymous users to add keywords to tickets. All we have > to do, as the community, is agree on the meaning of keywords that we > want to apply to tickets. i.e: > > r2g: ready to go > micro: a really small fix > typo, docs, etc > > As the core team members start to realize that things are being tagged > by the community, they''ll start searching on the tags. If you want to > contribute by tagging up a bunch of patches, I would think it would be > appreciated. > > > > -- > Kyle Maxwell > Chief Technologist > E Factor Media // FN Interactive > kyle@efactormedia.com > 1-866-263-3261
John Sheets
2006-Feb-09 13:05 UTC
Re: Still trying to get pagination fixed.. STILL havethis ActiveRecord connection helper thingy pending
On Feb 8, 2006, at 7:42 PM, Bob Silva wrote:> 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.Adding review remarks sounds like a good idea.> 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).Ditto. (And Ditto.)> 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".Maybe it''d be enough to add an [RPATCH] option to the patch description. "R" for "reviewed". Of course, that still leaves it with the honor system. Maybe that''ll be okay in practice. As long as it''s not the same person who submitted it! John -- John R. Sheets http://umber.sourceforge.net http://writersforge.sourceforge.net
Tom Ward
2006-Feb-09 13:52 UTC
Re: Still trying to get pagination fixed.. STILLhavethis ActiveRecord connection helper thingy pending
On 2/9/06, Bob Silva <me@bobsilva.com> wrote:> r2g and micro are pretty subjective though so I don't see how that helps the > core members any. They still have to review the patch, write and run unit > tests and any additional testing they so desire, assuming they can find the > time to do it.The core team shouldn't be left to write unit tests. They should be part of every submitted patch (unless the patch fixes a current failing test). I suggest one way we can all help is by going through and tagging patches with working tests, using a keyword like 'hastests'. The core team would then be able to concentrate on applying tested patches, while the rest of the community writes tests for those without. Any suggestions for a better keyword are welcome! Tom Ward _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Tom Ward
2006-Feb-09 14:27 UTC
Re: Still trying to get pagination fixed.. STILLhavethis ActiveRecord connection helper thingy pending
On 2/9/06, Tom Ward <tom@popdog.net> wrote:> Any suggestions for a better keyword are welcome!Talking to yourself, first sign of madness and all that, but instead of hastests I propose 'tested', to indicate that the patch has unit tests, and that those tests have been run. There's no reason submitters shouldn't add this keyword themselves, if they wish. Tom _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Scott Barron
2006-Feb-09 15:30 UTC
Re: Still trying to get pagination fixed.. STILLhavethis ActiveRecord connection helper thingy pending
On Feb 9, 2006, at 9:27 AM, Tom Ward wrote:> On 2/9/06, Tom Ward <tom@popdog.net> wrote: > >> Any suggestions for a better keyword are welcome! > > Talking to yourself, first sign of madness and all that, but instead > of hastests I propose ''tested'', to indicate that the patch has unit > tests, and that those tests have been run. There''s no reason > submitters shouldn''t add this keyword themselves, if they wish. > > TomWhat also would be helpful is if you review a patch and it applies cleanly and has tests that pass, that you not only tag it as you''ve suggested but also leave a comment with the svn revision that you reviewed it against. Sometimes things get updated or patches collide and it would be nice to have a frame of reference to say "ok, this did work at r12345, what''s changed?" in those times. Thanks -Scott
Rick Olson
2006-Feb-09 15:34 UTC
Re: Still trying to get pagination fixed.. STILLhavethis ActiveRecord connection helper thingy pending
> Talking to yourself, first sign of madness and all that, but instead > of hastests I propose ''tested'', to indicate that the patch has unit > tests, and that those tests have been run. There''s no reason > submitters shouldn''t add this keyword themselves, if they wish. > > Tomhere''s a query for the keyword: http://dev.rubyonrails.org/query?status=new&status=assigned&status=reopened&order=priority&keywords=tested&keywords_mode=~ -- Rick Olson http://techno-weenie.net
Michael Koziarski
2006-Feb-09 21:22 UTC
Re: Still trying to get pagination fixed.. STILLhavethis ActiveRecord connection helper thingy pending
> Talking to yourself, first sign of madness and all that, but instead > of hastests I propose ''tested'', to indicate that the patch has unit > tests, and that those tests have been run. There''s no reason > submitters shouldn''t add this keyword themselves, if they wish.Tested sounds like a great addition. I''d like to propose two more: * trivial - for tiny patches which we could apply in 15 minutes or so. Typically this is a typo fix, a fix for handling nil somewhere that we currently don''t. Something which is pretty simple to review and apply. * notests - For patches submitted without unittests These should also be marked XPATCH, because barring exceptional circumstances (or trivial fixes) we don''t apply patches which don''t include tests. We can set up two more reports for these. We''ll keep the trivial queue relatively empty, and people who want to help out can add tests to the notests patches. Thoughts? Comments? -- Cheers Koz
Bob Silva
2006-Feb-10 00:32 UTC
RE: Still trying to get pagination fixed.. STILLhavethisActiveRecord connection helper thingy pending
Sounds logical enough. I tried to see if the ''trivial'' would create conflicts with the trivial severity option that exists, but the custom search interface is broken with a missing javascript function so that you cant filter based on attributes of the ticket. Bob -----Original Message----- From: rails-core-bounces@lists.rubyonrails.org [mailto:rails-core-bounces@lists.rubyonrails.org] On Behalf Of Michael Koziarski Sent: Thursday, February 09, 2006 1:22 PM To: rails-core@lists.rubyonrails.org Subject: Re: [Rails-core] Still trying to get pagination fixed.. STILLhavethisActiveRecord connection helper thingy pending> Talking to yourself, first sign of madness and all that, but instead > of hastests I propose ''tested'', to indicate that the patch has unit > tests, and that those tests have been run. There''s no reason > submitters shouldn''t add this keyword themselves, if they wish.Tested sounds like a great addition. I''d like to propose two more: * trivial - for tiny patches which we could apply in 15 minutes or so. Typically this is a typo fix, a fix for handling nil somewhere that we currently don''t. Something which is pretty simple to review and apply. * notests - For patches submitted without unittests These should also be marked XPATCH, because barring exceptional circumstances (or trivial fixes) we don''t apply patches which don''t include tests. We can set up two more reports for these. We''ll keep the trivial queue relatively empty, and people who want to help out can add tests to the notests patches. Thoughts? Comments? -- Cheers Koz _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Tom Ward
2006-Feb-10 10:13 UTC
Re: Still trying to get pagination fixed.. STILLhavethis ActiveRecord connection helper thingy pending
On 2/9/06, Michael Koziarski <michael@koziarski.com> wrote:> * notests - For patches submitted without unittests > > These should also be marked XPATCH, because barring exceptional > circumstances (or trivial fixes) we don't apply patches which don't > include tests.Going through and marking untested (or otherwise deficient) patches XPATCH is an excellent idea - reducing the patch queue, and inviting help in areas that need it. I'm less keen on the 'notests' keyword, as I can't see what value it adds to the XPATCH flag. A simple comment ('This patch looks complete, but has no tests') would be enough for me. Some broader designation that a patch is 'nearly there' might be more useful, splitting patches that need loads of work from those that don't. In the end though, it's not worth the time obsessing about. Let's try out these ideas and see which ones stick. Tom -- email : tom at popdog.net _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core