Peekay Ex <pkx1...@gmail.com> writes: > So does that mean we are considering this 'staging' branch push > experiment a (near) success or at least something we all agree on or > is that another GOPpy thing? - I know we've had some minor > inconveniences with this method that requires knowledge of git more > than we have needed in the past. I.e it's 'easier' to cry foul and fix > master than push-merge-fetch-rebase-thingy :) even if it is more > serious when master breaks than staging.
The point is that you can't fix master, regardless of how long you cry foul. If something bad gets into master, it stays. Forever. If it breaks some regtest, it will break this regtest still in 10 years when somebody is trying to do bisection in order to find out when something went bad. And you can't push to master anyway without having rebased (or merged, which one does not usually want to see upstream) your development branch to its current state, so I have trouble understanding your problem. I don't think that "we are considering this staging branch push experiment a (near) success". The state more or less is that most of the people involved with it are willing to get it to a state where one can seriously evaluate it. But I do think there is some agreement that we are considering the master branch push experiment a reliably recurring failure. And the consequences get more expensive the more developers are working on Lilypond. Going through staging with an automated test procedure is going to help. It might at some point of time be possible to install hooks at the repository that deflect pushes to master right around to staging without asking. If you have a better suggestion how to deal with the "master gets broken frequently" phenomenon, go ahead. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
