where is mariadb-10.0.21-1.fc23 ?

[Andrew Lutomirski]

On Thu, Nov 12, 2015 at 8:31 AM, Josh Boyer <jwboyer at fedoraproject.org> wrote:
> 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 :).

Done: https://bugzilla.redhat.com/show_bug.cgi?id=1281536

Hopefully bugzilla is the right place for this.

--Andy