I''ve just been stung by #6353 (http://dev.rubyonrails.org/ticket/6353; "Undefined method recycle! in integration test with put or delete") in a Rails 1.2.3 project (specifically, I''m using form_test_helper, but it seems more general than that). The problem has been solidly fixed in edge, but I''m wondering if it''s worth backporting the fix to stable. (No, upgrading world+dog to edge is *not* an option). What''s the procedure to make that happen? Reopen the ticket, set the version to 1.2.3, and comment saying that it needs application to stable? Presumably I''d need to supply a patch that works against stable, which I''m happy to do. Should I make sure other people believe the patch is worth going into stable by discussing it here before doing that? - Matt --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
+1, This conversation feels familiar... ------- Courtenay On Aug 14, 2007, at 2:58 PM, Matthew Palmer <mpalmer@hezmatt.org> wrote:> > I''ve just been stung by #6353 (http://dev.rubyonrails.org/ticket/6353; > "Undefined method recycle! in integration test with put or delete") > in a > Rails 1.2.3 project (specifically, I''m using form_test_helper, but > it seems > more general than that). The problem has been solidly fixed in > edge, but > I''m wondering if it''s worth backporting the fix to stable. (No, > upgrading > world+dog to edge is *not* an option). > > What''s the procedure to make that happen? Reopen the ticket, set the > version to 1.2.3, and comment saying that it needs application to > stable? > Presumably I''d need to supply a patch that works against stable, > which I''m > happy to do. Should I make sure other people believe the patch is > worth > going into stable by discussing it here before doing that? > > - Matt > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> I''ve just been stung by #6353 (http://dev.rubyonrails.org/ticket/6353; > "Undefined method recycle! in integration test with put or delete") in a > Rails 1.2.3 project (specifically, I''m using form_test_helper, but it seems > more general than that). The problem has been solidly fixed in edge, but > I''m wondering if it''s worth backporting the fix to stable.Yes, if you feel the fix warrants backporting just reopen the ticket once you''ve managed to back port the fix. Most of the time the backport is simple enough, but some areas have received significant changes in edge.> (No, upgrading > world+dog to edge is *not* an option).Agreed.> What''s the procedure to make that happen? Reopen the ticket, set the > version to 1.2.3, and comment saying that it needs application to stable? > Presumably I''d need to supply a patch that works against stable, which I''m > happy to do. Should I make sure other people believe the patch is worth > going into stable by discussing it here before doing that?Generally we''ll backport any bug fixes without much objection. The only cases where that won''t happen are where the bug was fixed as a result of some heavy-duty changes to a given area of the codebase. However if another fix can be found, there''s no reason not to apply that. On another note, it''s about time to get serious about releasing another 1.2.x, but before we do that we should get an idea of what other fixes warrant backports, and get patches ready for that. Perhaps some of the participants in this thread could spend some time reviewing the changelogs / timeline and figuring out which fixes they''d like to see merged. I''m happy to handle committing all the patches and reviewing them, but as I''ve been on edge for some time, I''m certainly not the right person to know what''s still annoying 1.2.x developers. -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, Aug 15, 2007 at 11:27:53AM +1200, Michael Koziarski wrote:> > I''ve just been stung by #6353 (http://dev.rubyonrails.org/ticket/6353; > > "Undefined method recycle! in integration test with put or delete") in a > > Rails 1.2.3 project (specifically, I''m using form_test_helper, but it seems > > more general than that). The problem has been solidly fixed in edge, but > > I''m wondering if it''s worth backporting the fix to stable. > > Yes, if you feel the fix warrants backporting just reopen the ticket > once you''ve managed to back port the fix. Most of the time the > backport is simple enough, but some areas have received significant > changes in edge.The patches I''m looking at (so far) apply trivially and DTRT. If there are patches that aren''t clean, then they''ll obviously need to be cleaned up before they can be applied.> > (No, upgrading > > world+dog to edge is *not* an option). > > Agreed.I added that because so often the answer given by projects to "these bugs $are in STABLE" is "upgrade to $BLEEDING_EDGE".> > What''s the procedure to make that happen? Reopen the ticket, set the > > version to 1.2.3, and comment saying that it needs application to stable? > > Presumably I''d need to supply a patch that works against stable, which I''m > > happy to do. Should I make sure other people believe the patch is worth > > going into stable by discussing it here before doing that? > > Generally we''ll backport any bug fixes without much objection. The > only cases where that won''t happen are where the bug was fixed as a > result of some heavy-duty changes to a given area of the codebase. > However if another fix can be found, there''s no reason not to apply > that.Okie. One question I forgot to ask before -- do we go through the +1 process/verified process, or do I just set ''verified'' immediately to get it into the verified report (on the basis that, if the fix went into edge, the patch is probably OK)? Should there be (is there) a tag specifically for "this needs to be applied to the stable branch"? Nothing jumped out at me in http://dev.ror.o/reports.> On another note, it''s about time to get serious about releasing > another 1.2.x, but before we do that we should get an idea of what > other fixes warrant backports, and get patches ready for that. > Perhaps some of the participants in this thread could spend some time > reviewing the changelogs / timeline and figuring out which fixes > they''d like to see merged. I''m happy to handle committing all the > patches and reviewing them, but as I''ve been on edge for some time, > I''m certainly not the right person to know what''s still annoying 1.2.x > developers.I''ll see what I can do in that line, but others should probably chip in their favourites as well. - Matt --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Tue, Aug 14, 2007 at 04:06:40PM -0700, court3nay wrote:> +1, This conversation feels familiar...I couldn''t find any previous discussions of this in the list archives. Did my search miss something? (If it''s been discussed before, pointers appreciated) - Matt --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Feels like this ticket keeps cropping up. Maybe it was on IRC. Anyway, this is the only bugfix for which I brave the uncertainties of edge (it enables my spider tests to fuzz forms) ------- Courtenay On Aug 14, 2007, at 6:39 PM, Matthew Palmer <mpalmer@hezmatt.org> wrote:> > On Tue, Aug 14, 2007 at 04:06:40PM -0700, court3nay wrote: >> +1, This conversation feels familiar... > > I couldn''t find any previous discussions of this in the list > archives. Did > my search miss something? (If it''s been discussed before, pointers > appreciated) > > - Matt > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> I added that because so often the answer given by projects to "these bugs > $are in STABLE" is "upgrade to $BLEEDING_EDGE".Yeah, while we have a tradition of running on edge, I''m not going to suggest that it''s a good practise though.> Okie. One question I forgot to ask before -- do we go through the +1 > process/verified process, or do I just set ''verified'' immediately to get it > into the verified report (on the basis that, if the fix went into edge, the > patch is probably OK)? Should there be (is there) a tag specifically for > "this needs to be applied to the stable branch"? Nothing jumped out at me > in http://dev.ror.o/reports.Lets just use http://dev.rubyonrails.org/report/19 Tickets get there by being tagged with ''needs_review''. If the patch applies more or less cleanly, we can skip the review stuff, if the bug needs a wholly different fix we''ll do some more rigorous reviewing. However I think that it''s unlikely to be necessary.> I''ll see what I can do in that line, but others should probably chip in > their favourites as well.Absolutely, people who have ''annoying bugs'' they want fixed in 1.2.x should probably do some trac searching, or jump into #rails-contrib and ask around. Once we get a sense for the size of the problem, we can schedule a rough release date. -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, Aug 15, 2007 at 02:41:26PM +1200, Michael Koziarski wrote:> > I added that because so often the answer given by projects to "these bugs > > $are in STABLE" is "upgrade to $BLEEDING_EDGE". > > Yeah, while we have a tradition of running on edge, I''m not going to > suggest that it''s a good practise though.Like a lot of open source, the instability of edge rails is fairly minimal. It''s just that you can''t *rely* on it to not fall apart on you, especially when there''s people using it that don''t have the skills to fix it up again...> > Okie. One question I forgot to ask before -- do we go through the +1 > > process/verified process, or do I just set ''verified'' immediately to get it > > into the verified report (on the basis that, if the fix went into edge, the > > patch is probably OK)? Should there be (is there) a tag specifically for > > "this needs to be applied to the stable branch"? Nothing jumped out at me > > in http://dev.ror.o/reports. > > Lets just use http://dev.rubyonrails.org/report/19 Tickets get there > by being tagged with ''needs_review''.Sold. I''ve tagged one patch that I think should go in, and danger has reviewed it too. There''s one old patch in that report already that looks a bit fruity (#4492) but I''ll leave that for someone else to deal with. Thanks for applying #6353 already, by the way. <grin> - Matt -- I really didn''t foresee the Internet. But then, neither did the computer industry. Not that that tells us very much of course -- the computer industry didn''t even foresee that the century was going to end. -- Douglas Adams --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---