Re: Pushing patches to staging

[David Kastrup]

Peekay Ex <address@hidden> 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