On Wed, Oct 26, 2011 at 07:04:48AM -0600, Colin Campbell wrote: > Procedurally, I gather that the patch meister doesn't really care > whether a patch is on /staging or /master, only that Patchy has > checked it, and that there are no howls of protest in the discussion > on Rietveld or the various lists, before marking it for countdown, > and eventually for pushing.
Yes, but the patch should not be on either /staging or /master until after the countdown. > However, the first point above is > ambiguous: if a patch only gets to staging by way of a countdown, > then wanting it pushed immediately is moot. Yes-ish. Basically, the idea is that we forbid anybody from pushing to master. Work flow is this: - pull from master. - start editing files. - commit changes, upload to rietveld, optionally push to a dev/whatever branch - reviews, countdown - push to dev/staging - patchy compiles dev/staging, makes sure it doesn't die, and then merges dev/staging to dev/master. The idea is that we should NEVER have a broken master. Whenever somebody checks out lilypond git, they should be able to compile it. (I know that you've had a lot of pain running into broken stuff on master) > I had the impression that staging was for potentially disruptive > patches, those which might cause large-scale weeping and > wailing, and so should go into a sort of extra sanity check > before going onto master. No. dev/staging is for any patch that wants to go to master. I'm not going to insist on this... but rather, if somebody pushes something to master and it breaks, I will yell at them. Some people are extremely reliable about only pushing well-tested patches. Other people are generally reliable but occasionally slip up and/or don't mind a delay of 12 hours. Some people have a habit of pushing broken patches, or patches that did work but they made "one last change" which broke stuff. I want the latter group to ONLY push to dev/staging. The former groups can either use staging or push directly to master, as long as they accept the risk. Other than the extra pain of git, there is no downside to pushing to dev/staging instead of master. > Given that the Bug Squad verify patches with current GUB, can we > label patches which are fixed in /staging differently from those > which are fixed in GUB, so that a patch marked "fixed" is assumed > *not* to be in the GUB build? This might be a developer error, > simply forgetting to update the tag, but it could also mean the > patch is not yet in the publicly available rele4ase. that is a concern, but I have no energy left to be concerned about it. Note that merging from dev/staging to master will be completely automatic (including the tests to determine if this is safe). hmm, I suppose you could add a "staging" tag to google code, then patchy could automatically remove any "staging" tag when he merges it. Although there's a potential for "multi-processing" scheduling flaws; if somebody pushes something to staging after patchy starts testing it, he'd still remove that "staging" tag. I don't think it's a huge issue. If staging can't merge, we'll have a big wailing and gnashing of teeth, so we're not going to lose those patches. And I'm not going to make a release while we're in the middle of staging-wailing-gnashing. The most important thing, in my mind, is to stop the idiotic breaking git master once a month that seems to be our custom. We should never have new contributors trying to build lilypond and/or the docs and have the compile break. - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
