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 :). josh -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
