Getting patches applied to stable?

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

+1, This conversation feels familiar...

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.

> 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

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

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)

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.

> 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