On Fri, 2016-01-22 at 10:37 -0600, Michael Catanzaro wrote: [...] > I really don't think it's a big deal to have a few reverts in the git > history. And anyway, reverts should be relatively rare, because build > breakage should be relatively rare. > > The master branch may be unstable, but that doesn't mean build > breakage > is ever acceptable. If your code is not buildable at all times in > Continuous, keep it on a *side branch* -- otherwise, tag your module > in > Continuous, branch it in jhbuild, and do whatever you want in master. > But as long as you have an official GNOME module, if it's not > branched > and tagged, master needs to build. This isn't the wild west.
Of course, when you commit something and your *own* code does not compile, this is a very, very rare thing, rare enough to not be worth discussion I think, it that's happening, it's a problem. But it's common enough with many moving parts that the breakage is indeed intentional, in which case screwing with the history is only intrusive. > > > My interpretation of your proposal is that you would want to > > revert > > this api break or behavioral change if it were found to break > > the > > build (or the tests) of another module, during this unstable > > development period. > > > > This would obviously be wrong and would just be an obstacle to > > progress in the cases where breakage is intentional and the > > only > > correct solution is to have applications adapt to the new API > > or > > behavior before the next stable release. > > It's a big problem that some modules break for days or weeks at a > time > during API transitions; this makes it very difficult for new > contributors to build and run GNOME, and it's inconvenient for > experienced contributors as well. This kind of breakage is just a fact of life, you cannot sweep it under the rug and pretend it does not exist. Sure, it's a barrier of entry for newcomers and an annoyance for experienced developers who realize the facts of life. But that's just the way it is, there is no reason to complain about it. Software development is difficult, integration is difficult when you have many moving parts that are in a development stage before being release ready. [...] > To be clear: if you've branched and tagged your module, then you do > whatever you want in master without hurting anyone else. But > otherwise, > master needs to be buildable. And to be doubly clear: the master branch is *not* what is advertised by upstream maintainers as stable, it is the bleeding edge, it can have churn, it may not always match up to other modules perfectly, other modules may have not yet adapted to the churn. Building master may be asking for trouble, again, this is just a fact of life if you are trying to integrate with all bleeding edge component in the middle of their development cycle, instead of what maintainers have published as stable. If you want something that you are sure will build, take the stable release tag and build that. Best, -Tristan _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
