On Mon, Nov 2, 2015 at 7:16 PM, Andrew Lutomirski <luto@xxxxxxx> wrote: > 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. Task-o-tron runs upgrade path checks when you file updates. It automatically tells you if the upgrade path is broken (or it very much used to). So you can simply choose not to push it to stable until it's sorted out. I will agree that automating the "don't push to stable" bit would be nice though. I might be tainted by the kernel workflow here, where we disable autokarma and manually choose to push to stable based on various other factors. josh -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
