On Fri, 2016-01-22 at 11:40 -0600, Michael Catanzaro wrote:
> On Fri, 2016-01-22 at 09:25 -0800, Jasper St. Pierre wrote:
> > It's more frequent than you might think.
> > 
> > In the past week, alone, we've had to tag glib, gnome-calculator,
> > e-d-s, gstreamer, and more, all because of broken builds. Take a
> > look
> > at how busy gnome-continuous is as a project:
> > https://git.gnome.org/browse/gnome-continuous/log/
> 
> Absolutely. I should be more clear: it doesn't happen so often for
> any
> PARTICULAR module, so the git history of any particular module is not
> likely to get polluted by many revert commits. (And even if it does
> --
> so what if your history doesn't look quite as nice as you'd like.)
> But
> it happens a LOT for GNOME as a whole, and it's a big problem, which
> is
> why I'm so supportive of Emmanuele's plan.

I am still a bit baffled by this, as I expect a higher standard of
quality from GNOME contributors than I would for your regular corporate
r&d lab.

So let me reiterate what I mentioned in my first email, I am not
against this proposal for the stable branches, and, for master: I think
Emmanuele's proposal needs clarification.

To clarify what I mean by that, is it should be clear what a sheriff
has, and has not the right to revert. If I committed a spelling error
which obviously broke the build of my own module, *doh*, of course,
it's a single commit, a stupid one, and I really couldnt care less if
it were to be reverted by someone else who caught the error. Jasper
seems to indicate that this kind of thing actually happens more than I
would expect, this is indeed sloppy and should be addressed.

I do not support the vague notion that a "sheriff" can come along and
revert an entire branch I've just landed which changes the API contract
early enough in the release cycle for depending modules to catch on and
adapt to.

As I have elaborated enough in my reply to Shaun, this kind of thing
happens, frequently enough, and there are transitional periods where
building all of GNOME and expecting everything to build is just not
rational, responsible maintainers will be careful to introduce churn as
early as possible in the cycle.

Best Regards,
    -Tristan

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Reply via email to