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