Graham Percival <gra...@percival-music.ca> writes: > On Mon, Aug 13, 2012 at 08:16:48PM +0200, David Kastrup wrote: >> Werner LEMBERG <w...@gnu.org> writes: >> > Hmm, `wild changes' is a mild exaggeration, isn't it? It makes >> > 50 Cyrillic characters appear in the PDFs which were simply missing >> > previously. It's a one-line change in `macros.itexi' >> > and a new file. And of course I've run `make doc' on a freshly cloned >> > git repository and checked the output whether everything is fine. > ... >> And even when the wild code bonanza has started, we will have review >> processes, and I, like every other developer, have the right to mention >> my concerns in reviews when changes with large impact are made. > > Yes. Pushing directly to staging is basically a gamble: > IF YOU WIN: you avoid the delay and hassle of git-cl, reviews, a > patch countdown, etc. > IF YOU LOSE: somebody doesn't like something in your patch and is > annoyed that they didn't have a chance to comment.
I don't see it as a gamble. Pushing to staging means "I consider this change to be safe and can't imagine anybody suggesting anything to change". Not "I hope nobody will notice", but "I don't expect anybody to be concerned". With a _gamble_, you have open expectations. And if that is the case, you should use the review process. Pushing to staging is where you are _certain_ that no review is called for, needed and wanted. Typo fixes where you are reasonably sure of your grammar. Comment fixes where the comment does not agree with the code. Bug fixes that have an obvious solution. And so on. > Honestly, if I were in Werner's position, I probably would have > done the same. I wouldn't. For changes with potentially large impact, I use a review even when I am of the opinion that I am by far the best-suited programmer for dealing with a particular problem. > -- I would have taken the risk that everybody was ok > with the change, and pushed it directly to staging. But as soon > as somebody complained (regardless of who it was, regardless of > the reason), I would revert the commit, and send the patch for > review+countdown. I don't think it makes sense to push every change tentatively to staging and see whether one can get through with that. > it's a gamble, and it didn't pay off in this case. I would prefer it if people don't gamble the development processes. It is disrespectful to other developers to consider them irrelevant. So I would very much like to see "push to staging" restricted to those cases where there is a reasonable expectation that everybody would fully agree with form, content, and intent of a change. > In the future, we'll all remember that changes to texinfo.tex can be > problematic, so we'll be slightly less likely to take the gamble with > that file. It was not a change to texinfo.tex, but macros.itexi is technically used even more (if you also count the invocations in non-TeX modes). And it is not a fuzzy "can be problematic" here. It is a change with large effects which is part of the reason Werner considers it desirable. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel