On Mon, Nov 2, 2015 at 6:42 PM, Kevin Fenzi <kevin@xxxxxxxxx> wrote: > On Mon, 2 Nov 2015 15:30:41 -0800 > Andrew Lutomirski <luto@xxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
