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