On Mon, Nov 2, 2015 at 6:42 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Mon, 2 Nov 2015 15:30:41 -0800
Andrew Lutomirski <luto(a)mit.edu> wrote:
> This has been bugging me for a while: what's the best practice, or
> even a good practice, for pushing updates to more than one Fedora
> version at a time?
>
> Suppose I that foo-1.0-1 is current in fc22, fc23, and rawhide. I
> want to update them all to foo-1.0-2.
>
> Obviously step 1 is to build all three new versions. Rawhide
> automatically picks up the new build at the next compose. All is
> well.
..snip...
> Is there some other workflow that makes sense here?
I think you are overthinking it.
Yep.
Personally, I build everything, test locally, then either create
updates with 'fedpkg update' in each branch, or go to the web interface
(that lets you make all of them at once for multiple branches), and
leave close bugs on stable set.
Sure then if your f23 update goes stable the bug gets closed, but if
there's still a problem you can re-open it. If not, bodhi actually
updates the 'fixed in' field with the other updates when they go stable
too.
We do this for the kernel as well. Yes, that means f22 bugs get
closed when f23 is stable, or f23 bugs get closed when f21 is stable
(that happens), but from a maintainer perspective it's just as
accurate. We fixed the bug, it's in Fedora git, it's in a build, it's
available in the branches, and there are comments in the bugs pointing
to all the various branches. Beyond that, it's just mechanics and
automation. We don't actually have to _do_ anything after the update
has been filed.
The alternative would be to basically setup a tracker bug (the
problem/issue) with blocks subbugs for each release, which IMHO is way
too much overhead. People are perfectly capable of seeing a bug that
was closed for f23 is still applicable to the f22 update thats in
testing and has the bug attached to it.
Yeah, I've seen people do this before. It's a thing that can be done
if you're really pedantic about bugzilla states, but 9 times out of 10
the solution to bugzilla inflexibility is not to add more bugzilla on
top of it.
josh