where is mariadb-10.0.21-1.fc23 ?

[Sérgio Basto]

On Qui, 2015-11-12 at 09:06 -0800, Andrew Lutomirski wrote:
> On Thu, Nov 12, 2015 at 8:31 AM, Josh Boyer <jwboyer at fedoraproject.or
> g> 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.e
> > > > du> 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 m
> > > > > > it.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.

I read your RFE , "Please consider adding a Bodhi feature ... " 

This feature is: Bodhi should verify before push the package to stable,
if package have the same or lower NVR of the next branch, if not,
doesn't let you push the package and give the user the feedback why
can't push the package. When it is fixed, Bodhi maybe can push it
automatically or notify the user that already can be pushed . 


> --Andy
-- 
Sérgio M. B.