Re: PATCH: Countdown to 20110925

[address@hidden]

On Sep 24, 2011, at 11:39 AM, Graham Percival wrote:

> On Sat, Sep 24, 2011 at 11:16:35AM +0200, address@hidden 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