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