Update pushing and bugzilla workflow

[Josh Boyer]

On Mon, Nov 2, 2015 at 6:42 PM, Kevin Fenzi <kevin at scrye.com> wrote:
> On Mon, 2 Nov 2015 15:30:41 -0800
> Andrew Lutomirski <luto at 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