On Nov 12, 2015 8:17 AM, "Josh Boyer" <[email protected]> wrote: > > On Thu, Nov 12, 2015 at 11:07 AM, Andrew Lutomirski <[email protected]> wrote: > > > > On Nov 12, 2015 7:21 AM, "Josh Boyer" <[email protected]> wrote: > >> > >> On Thu, Nov 12, 2015 at 10:16 AM, Andrew Lutomirski <[email protected]> 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. --Andy > > josh > -- > devel mailing list > [email protected] > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- devel mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
