Hi, A revert is not supposed to be "punishment" in any way... rather, consider it as assistance to make sure GNOME stays buildable. :) But if you really don't like it and don't want other folks reverting your commits when you're not around, we can create a list of maintainers who don't want this; that way, on the rare occasions when something breaks, we can branch your module in jhbuild and tag it in Continuous instead of reverting your change. I think it's generally better to avoid branching/tagging, so I'd encourage maintainers to just accept the occasional revert now and then, but it's understandable if we won't all agree on this.
On Mon, 2016-06-06 at 11:01 +0200, Milan Crha wrote: > - a soname version bump can break dependant projects. Such change > should not be reverted, the dependencies should be rebuilt. Right; incremental builds with jhbuild are not completely reliable, and a soname bump is generally not a valid reason to revert a commit. But if a clean build doesn't work, then we have a problem to be fixed. > - a soname version bump with an API change can break dependant > projects. Such change should not be reverted, the dependencies > should be rebuilt and adapted to the change. In this case, when the API change breaks something in core or gnome- apps, then the module and its dependencies really need to be updated in jhbuild at (approximately) the same time, so there's at most a small window of time where jhbuild is broken. Of course it can take time to port dependencies; in such cases, we can either (a) make the API change on a side branch, port dependencies on side branches, and merge the changes to master when all GNOME modules are ready; or (b) make the API change on master, but branch the module in the jhbuild moduleset so that other modules continue to build against the older version of the module with the API change. Really, you can do whatever you want, so long as you avoid breaking jhbuild or Continuous, please! > - a change which can build, but causes regressions in runtime. Such > change should be reverted, right? But wait, you care only about > the build, not about runtime. Having a software buildable and > having the same software usable are two very different things. Yeah, of course runtime bugs are problems, but not the problem we are trying to solve here. :) Hope that clarifies where I'm coming from. Michael _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
