On Mon, Nov 2, 2015 at 4:14 PM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > 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. > > 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
