where is mariadb-10.0.21-1.fc23 ?

[Andrew Lutomirski]

On Nov 12, 2015 8:17 AM, "Josh Boyer" <jwboyer at fedoraproject.org> wrote:
>
> On Thu, Nov 12, 2015 at 11:07 AM, Andrew Lutomirski <luto at mit.edu> wrote:
> >
> > On Nov 12, 2015 7:21 AM, "Josh Boyer" <jwboyer at fedoraproject.org> wrote:
> >>
> >> On Thu, Nov 12, 2015 at 10:16 AM, Andrew Lutomirski <luto at mit.edu>
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
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20151112/d8d97864/attachment.html>