"Trevor Daniels" <t.dani...@treda.co.uk> writes: > Graham Percival > >> Developers doing medium-large fixes: examples include beam >> collisions, music function rewriting, Flag grobs, etc. All this >> work should go on separate branches (e.g. dev/flag-grob, >> dev/scheme-music-functions). Once the code is merged, the branch >> should be removed. People can still use dev/myname instead, but I >> think that naming these branches after the feature (or bugfix) >> will be more clear. > > How would this code be reviewed? Do you envisage still > uploading to Reitfeld? Would this be before pushing to > dev/* or after? I still think this is a complication too far. > Certainly it needs more thought and comment from the 'big' > developers before being adopted.
It is a compromise between the damage and the good developers manage to do. The higher the number of developers, the more important it becomes to avoid damage, since damage blocks everybody, and good initially helps only a single application. I have not exactly been the paragon of damage avoidance lately. Part of the problem is a quite old single-core development system making it very expensive to do a full check, particularly on small changes. Another part of the problem is working on several interlocking changes with related features: it does not make sense to write independent documentation for interlocking features, and it is not really feasible to create independently working reviews, so I try to flush out the base work rather sooner than later in order to make it possible to let the work on top be reviewed at all. Obviously, I have not yet found a balance in the current development process where I don't turn into an annoyance. A staging branch might be a step in the right direction. > My preference is for a single staging branch. Major patches would be > pushed there rather than to master after a successful Reitfeld review, > and only cherry-picked to master after successful tests (eg doc build) > by someone authorised to do so. I am not sure cherry-picking is the way to go. The main point of a staging branch is that you can do a full doc and reg test for a bunch of changes together. When cherry-picking, this becomes more difficult. Basically a staging master would then to have to cherry-pick to his private staging branch (tracking origin/master), make full builds and verifications, then push (only fast-forward!). Afterwards rebase the public staging branch on master and push, so that all committed changes will no longer be present. Hm, not all that bad. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
