Note: quoting is not correct (probably because of replying on phone). On Mon, Nov 09, 2015 at 11:19:16AM +0100, Vincent van Ravesteijn wrote: > >> 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.
Social pressure does not work with everyone. Also, some people do not understand why certain things are so frustrating to others. > 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. OK. How about a 1 week rule then? Or you would prefer no rule and just deal with it case-by-case and implicit rule as you mention below and as Guillaume refers to? > 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, Yes this is indeed a real issue. Maybe in the future once everyone is more comfortable with git we can consider this. > - 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). Seems like we cannot do this at this point then. Scott
