I have noticed at the dev.rubyonrails.org site that many tickets with pretty clear-cut bug reports/patches or feature enhancements don''t get any attention. They sit there for months at a time. Why is this? Are tickets from those that are not in rails-core deprioritized? Are there just not enough people that have the power to act on tickets? I know it''s not lack of test cases because I see tickets with test cases attached that are also ignored. It seems like just some sort of response would be helpful, even if it is as simple as "we are not going to add/fix this at this time". For example: http://dev.rubyonrails.org/ticket/6684 http://dev.rubyonrails.org/ticket/4918 http://dev.rubyonrails.org/ticket/4807 (this got a response, but no subsequent action) http://dev.rubyonrails.org/ticket/5388 -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I am curious about this as well. I submitted a patch with test cases 4 months ago, it got looked at after about 3 or 4 weeks, and needed a fix. I fixed it and it''s been sitting there for 3 months. I think "not enough people/time" is a valid reason for why patches don''t get applied, but it would be helpful to know that so that people who submit patches can understand more about the process. I just submitted another patch last week, and I have no idea when/if it will be applied. Wes -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 1/23/07, Frank Kozlowski <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > I have noticed at the dev.rubyonrails.org site that many tickets with > pretty clear-cut bug reports/patches or feature enhancements don''t get > any attention. They sit there for months at a time. Why is this? Are > tickets from those that are not in rails-core deprioritized? Are there > just not enough people that have the power to act on tickets? I know > it''s not lack of test cases because I see tickets with test cases > attached that are also ignored. > > It seems like just some sort of response would be helpful, even if it is > as simple as "we are not going to add/fix this at this time".It takes a lot of time to go through and respond to tickets. Even those that are ready for primetime sap up a lot of your time. For instance, I spent almost 2 hours last night (Heroes, FTW!) going through some patches that were mostly doc patches and test cases and only made a tiny, unnoticeable dent. -- Rick Olson http://weblog.techno-weenie.net http://mephistoblog.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Rick Olson wrote:> It takes a lot of time to go through and respond to tickets. Even > those that are ready for primetime sap up a lot of your time.That is totally understandable. I guess my question still remains though - is it simply a numbers problem? Not enough people able to act on tickets? -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> I have noticed at the dev.rubyonrails.org site that many tickets with > pretty clear-cut bug reports/patches or feature enhancements don''t get > any attention. They sit there for months at a time. Why is this? Are > tickets from those that are not in rails-core deprioritized? Are there > just not enough people that have the power to act on tickets? I know > it''s not lack of test cases because I see tickets with test cases > attached that are also ignored.I have the same question. I submitted a patch for 4 bugs in 1.6 a few months ago, of which one is still not fixed in 1.2.1, namely the strange reversal of delete and destroy in case of clear on a has_many collection. Of course in this case it is "all hail monkey- patching", but still sad that all this code/maintenance is duplicated. Of course I understand that it can take time, but I don''t think that it would be hard to find more (good/trustworthy) people that are willing to check and integrate patches... For those impatient, the monkey-patch code below: --- module ActiveRecord module Associations class AssociationCollection # Removes all records from this association. Returns +self+ so method calls may be chained. # def clear return self if length.zero? # forces load_target if hasn''t happened already if @reflection.options[:dependent] && @reflection.options[:dependent] == :destroy destroy_all else delete_all end self end end end end --- greetings, Wybo -- ::Student: - History, Informatiekunde (computer linguistics, IR, webtech) and Philosophy - Member of the Center for Metahistory Groningen (http://www.rug.nl/let/cmg) ::Free Software and Open Source Developer: - http://www.LogiLogi.org, innovative system for cumulative, shared commenting, publication and idea sharing: Web as it should be... - ComLinToo, a computational linguistics toolset written in Perl - Lake (LogiLogi.org Make), a make-replacement using makefiles in pure C++ ::Being: - In the world, go figure (http://nl.logilogi.org/HomE/WyboWiersma) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---