Rails core - Feb 2006 - 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

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

> 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
Another layer could help I think.

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

> 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

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

> 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

> 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

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

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

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

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

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

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

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.
>
> Tom
What 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

> 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
here''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

> 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

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

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