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
