On Thu, Nov 12, 2015 at 8:31 AM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > On Thu, Nov 12, 2015 at 11:29 AM, Andrew Lutomirski <luto@xxxxxxx> wrote: >> >> On Nov 12, 2015 8:17 AM, "Josh Boyer" <jwboyer@xxxxxxxxxxxxxxxxx> wrote: >>> >>> On Thu, Nov 12, 2015 at 11:07 AM, Andrew Lutomirski <luto@xxxxxxx> wrote: >>> > >>> > On Nov 12, 2015 7:21 AM, "Josh Boyer" <jwboyer@xxxxxxxxxxxxxxxxx> wrote: >>> >> >>> >> On Thu, Nov 12, 2015 at 10:16 AM, Andrew Lutomirski <luto@xxxxxxx> >>> >> wrote: >>> >> > >>> >> > I think that Bodhi should arrange, at least by default, to push >>> >> > things >>> >> > in >>> >> > the correct order. Whether that means that karma is required >>> >> > separately >>> >> > for >>> >> > each branch is an orthogonal issue, except insofar as allowing karma >>> >> > from >>> >> > one branch to carry over to another would also require Bodhi to track >>> >> > that >>> >> > two updates are the same thing but just to different branches. >>> >> >>> >> Two updates in separate branches are never the same thing. They may >>> >> be the same version of the specific package, but there is no guarantee >>> >> that: >>> >> >>> >> a) they were built with the same toolchain >>> >> b) they were built with the same configuration options >>> >> c) they were built for the same reasons >>> >> >>> >> While it would be convenient for developers to tell bodhi they are the >>> >> same, it's a lie we all tell ourselves. I don't think we should code >>> >> our update tool to lie. >>> >> >>> >> > At the very least, Bodhi should *not* push to F22 due to autokarma >>> >> > until >>> >> > F23 >>> >> > stable is requested. >>> >> >>> >> I certainly agree with this in principle, but it would force >>> >> everything (including rawhide composes) to be serial and the slowdown >>> >> would be significant. >>> >> >>> > >>> > I'm a bit confused. Wouldn't rawhide be unaffected because rawhide can >>> > always have newer versions without breaking the upgrade path? It's only >>> > the >>> > old branch (currently F22) that would be slower, no? >>> >>> If you are truly protecting upgrade paths in the manner which you >>> suggested, you would have to do them in this order: >>> >>> rawhide, f23, f22, f21, <repeat> >>> >>> so that updates to f23 do not break the upgrade path to rawhide. >>> >>> Complicating things even more is that as a release grows older, the >>> compose time for its updates repository also grows longer. The more >>> updates, the more to compose. Which means that from a time >>> perspective you might still be composing the oldest release (f21 in >>> this example) when it's time to start the next day's rawhide and now >>> you cannot. You lose the predictability of rawhide. >>> >>> If we ignore rawhide and focus only on stable releases, your >>> suggestion becomes more feasible. I'm not really sure it's worth it >>> in the long run though. From a practical standpoint, serializing >>> everything to protect upgrade path isn't really a solution to a >>> prevalent problem. The newer release (containing the equivalent >>> package update) will complete typically within a few hours of the >>> older release, and with mirror synchronization time taken into account >>> it isn't usually a major issue. >> >> Fair enough. >> >> We could start with a much more modest variant, though: ignore compose and >> just make autokarma pushes to any repo depend on the same or newer NVR being >> either pushed *or requested* for all the newer branches. That would avoid >> multi-day issues. > > Sounds like a reasonable RFE to file, yes :). Done: https://bugzilla.redhat.com/show_bug.cgi?id=1281536 Hopefully bugzilla is the right place for this. --Andy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
