where is mariadb-10.0.21-1.fc23 ?

[Josh Boyer]

On Thu, Nov 12, 2015 at 11:29 AM, Andrew Lutomirski <luto at mit.edu> wrote:
>
> 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.

Sounds like a reasonable RFE to file, yes :).

josh