>> Ideally, I would like for commits that break tests to be on a separate git >> branch. Once the bugs exposed by a commit are fixed or the tests are fixed, or >> the .lyx files are fixed, then the branch could be merged to master. This >> allows us to presere a "0 failing tests" situation on the master branch so it >> is extremely easy to catch regressions. So my preferred policy would be: if a >> commit is found to have broken a test, either the situation is resolved within >> a day (i.e. the bug is fixed or the test is fixed) or the commit is reverted >> (and perhaps pushed to a separate remote branch). > > > A small remark: imposing a 1-day rule seems ad hoc to me. Do we even have such rules for compilation warnings? For compilation failures? For the latter, I imagine that people want it solved ASAP, but this arises more out of social pressure, not an ad hoc rule. However I like the idea of having a "candidate" remote branch, which would open up possibilities. If that's really needed. >
Yes, the 1-day rule might lead to frustrated developers and increases the noise in master branch even more. And yes of course there is an implicit rule that when your commit breaks something or has problems whatsoever you are expected to fix it within a reasonable timeframe. I already proposed to have a "staging" branch where commits are pushed to first. If there are no breaking tests and no other comments they would be merged to master after n days. The problems with such a construction are: - devs are not eager to have to learn/understand/use an even more complex git-o-cratic workflow, - there will be merge conflicts, people have to make sure to indicate which commit depends on which (or use feature branches which takes us back to the first point), - you unavoidably need some sort of maintainer to decide what gets merged when and who resolves merge conflicts and is reasonably always present (or to try to use some autocomplex scripting). Vincent
