Update pushing and bugzilla workflow

[Andrew Lutomirski]

On Mon, Nov 2, 2015 at 4:14 PM, Josh Boyer <jwboyer at fedoraproject.org> wrote:
> 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.
>
>

I don't really care about Bugzilla states.  What I do care about (or
at least care about more) is not breaking the update path, and that
could be more automatic than it is right now.

-Andy