On Fri, 2016-06-03 at 08:28 -0500, Michael Catanzaro wrote: > I expect module maintainers to be understanding when reverts happen. > It's not the end of the world; you can land your change again as soon > as you figure out why it was broken. We can all live with a few > revert commits in our git history. Your module can still be your > fiefdom... just so long as it's still building with the rest of > GNOME.
Hi, I'm not a fan of the random reverts from some 3rd party person whom doesn't know the "bigger picture" of the project changes which can lead to a win-win state, even the changes are that large that it's better (for whatever reason) to split them into several commits, which not necessarily follow in a short time. Such reverts would mean more work for the maintainers, which is always a pita. I hear here an argument that the maintainers claim that "it builds on their machine" and they do not care of the other build environments. Personally, I do not understand this statement, one (the maintainer) should be willing to support his project home, appreciate that the project can use the infrastructure and be tested in more places, which is always a good thing. The proposal about random reverts makes me feel that you want to flip the positions. While I agree that the maintainers point of view is broken, the position flip just means (for me): "the GNOME infrastructure/jhbuild environment is the only good build environment and if the maintainer breaks it, then the GNOME infrastructure team can punish the maintainer if it needs to". Do you see how absurd it sounds? The breakage should be dealt with in a cooperation manner, rather than in a force manner. Of course, if the maintainer is not willing to cooperate..., but I hope that's only a minority of the GNOME-hosted projects (I do not know any numbers here) and definitely the core project maintainers are all good, I believe, thus there might not be any issue. The "bad" projects, if not from the core part, can be skipped in the Continuous builds due to the lack of the interest from the maintainers side. There had been discussed also what can be reverted and what not. If you recall: - a soname version bump can break dependant projects. Such change should not be reverted, the dependencies should be rebuilt. - 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. - 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. I suppose the GNOME build system runs some unit tests, if the module provides such, but such tests are testing the new code, not the regressions the change in the module can cause in another module which had been/will be built against it. Just my opinion on the matter. Bye, Milan _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list