On Sep 24, 2011, at 11:39 AM, Graham Percival wrote: > On Sat, Sep 24, 2011 at 11:16:35AM +0200, m...@apollinemike.com wrote: >> Then they should not be put on a countdown - I'm not sure which patches of >> mine will be review-ready by the time Colin sends out his weekly e-mail. > > It's three times a week. There should be no rush to "get stuff > added". Just make patches, mark them patch-new, and the process > will handle them.
Sorry - I don't know why I said weekly! > If the patch is good, it's pushed within 72 hours (unless there's > unusual load). If it's not good, you'll get comments within 72 > hours. > >> However, I also get the sense that from your >> comment above that you do not feel it is appropriate. Could you elaborate >> further on what would be a better way to go about this? > > Add every patch to code.google.com with a Patch-new issue (or > adding Patch-new to an existing issue, if it's a bugfix). Every > update to every patch should change that issue to Patch-new. > > Result: no missed patches. Every patch gets a regtest check > before it's reviewed, and every patch gets onto a countdown. > > I don't like asking developers to do this manually -- hence my > fussing around with modifying git-cl to do this automatically. > But if you're concerned about patches going missing, then go > through these manual steps for a week or two until the new git-cl > has been tested some more. > That's great! I didn't follow that you were doing that (I don't read all the stuff on devel), but that will help a lot. What would be useful in git-cl is a way to signal to the PatchMeister the developer's perceived importance of a patch. If I have 8 patches waiting to get pushed, I generally have a sense of which ones I'd like to get into a countdown sooner rather than later. Sometimes, this is obvious (i.e. if it fixes a Critical Issue). But sometimes this is less obvious (i.e. it is needed so that I can work on something else), in which case it'd be great if I could communicate this through git-cl. That way, if Colin is deciding between a batch of patches and there's a coin-flip between two patches from one developer, he'll have the developer's notes at his disposal to make the decision. Cheers, MS _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
