On Thu, 2016-01-21 at 14:54 +0000, Emmanuele Bassi wrote: [...] > This is not enough, and it does not raise the bar in keeping GNOME in > a buildable state. It actually lowers it a fair , to the effective > point that *nobody* cares about Continuous builds. > > I want this to change. I want to be able to revert failing commits on > the offending modules, if they are hosted on GNOME infrastructure, if > they fail for more than N hours, and *then* open a bug about it.
Hi Emmanuele, In GNOME, we have got along well for many years with many projects sharing the same infrastructure mostly because we find that in practice, people are generally respectful enough of eachothers work to recognize a module maintainer's word as scripture. As such we do not commit changes to others modules without expressed permission unless it is for a minor change that we are absolutely sure about. There is/was a page describing this policy to those who receive commit access explaining the responsibility that comes with being a committer, it has either gone missing or I cannot currently find the text. In that context, I admit that I first interpreted your proposal as hostile, at least in it's current form, because it violates this policy which has allowed our projects to exist in harmony for so many years under the GNOME umbrella, by awarding some kind of revert power to an arbitrary group of individuals. I can see much opportunity here for unnecessary dispute, if special care is not taken, we may risk incentivizing maintainers to host their projects elsewhere. On the other hand, it is desirable to have things building regularly, of course the master branch is inherently unstable - that's what it's for, but I would however support your proposal without hesitation were it to be applied to stable branches only. Were we to apply your proposed policy to master, I think we need further thought and clarification before carrying that out: o We are a volunteer driven project with contributors distributed across timezones, who have dayjobs, it is ridiculous to expect that maintainers can be reachable within a 3 hour turnaround period. This leads me to believe that you fully expect to cause friction by reverting commits before said maintainers have the time to even respond, and doing so on the unstable master branch. The master branch should ideally not be littered with reverts and reverts of reverts, it is the main history of project development and adding such noise to master should be avoided as much as possible for the purpose of preserving the integrity and value of the history. I think this is unfriendly at best and I would prescribe a one week period for master. We should really wait for the maintainers word before intruding and reverting commits which introduce breakages which may have even been intentional. o Not all libraries advertize API/ABI stability, especially when it comes to libraries whos only consumers are GNOME applications, we allow ourselves much more leniency here than with platform libraries which are also relevant outside of the GNOME ecosystem. During the course of unstable development, it is entirely common for a library to introduce a new API and then to later change it, even more than once before it is ready for a stable release. For instance, EDS's backend facing APIs are not stable, and there have been regular issues in the vala API it exposes and libfolks consumes. There are periods where it must be accepted that things are just broken in a transitional phase. 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. In summary, I am not opposed to applying your proposal as is to the stable builds, there is no justification *ever* for breakage in stable branches. For master, I only think this needs to be detailed properly, perhaps it would be enough to ensure we had policy ensuring that intentional breakage is announced (on this list ?) and that "sheriffs" are responsible for following this list and not reverting commits which break things intentionally in a transitional period. Regards, -Tristan _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list