patchwork states and workflow

patchwork states and workflow

[Kumar Gala]

Guys,

I've always been a bit confused about some of the states we can put a  
patch in.  For example, what does 'archiving' a patch mean?

What's the difference between 'deferred' and 'rejected'?  Is 'Under  
Review' useful?

My biggest question is how to manage the transition of 'Accepted' and  
'Awaiting Upstream' and having clear definitions of what we think  
these mean.

My preference is 'Accepted' means its been applied to someone's tree  
(mine, josh's, paul's, etc.) and 'Awaiting Upstream' is the state it  
goes into if we are waiting for a pull by Paul or Linus.  This does  
raise the issue of what state things should be in after the pull.

Comments?

- k

Re: patchwork states and workflow

[David Miller]

I'm not really interested in this dicussion, the states make sense
to me and I know how I will use them.

I'm also extremely backlogged as-is, and this will only compound
things.

Therefore, please drop me from the CC: list, thanks.

Re: patchwork states and workflow

[Paul Mackerras]

Kumar Gala writes:

> I've always been a bit confused about some of the states we can put a  
> patch in.  For example, what does 'archiving' a patch mean?

Archiving puts the patch away somewhere where it doesn't appear in the
normal pages and needs extra effort to get to, as I understand it.

> What's the difference between 'deferred' and 'rejected'?  Is 'Under  
> Review' useful?

Deferred usually means the patch depends on something else that isn't
upstream, such as patches that only apply against the RT tree.
Rejected means we just don't want to do what the patch does.

> My biggest question is how to manage the transition of 'Accepted' and  
> 'Awaiting Upstream' and having clear definitions of what we think  
> these mean.

I put patches into "awaiting upstream" when I put them in a bundle, so
it means that they have entered my QA process.  When they're in my
public tree, I put them into "accepted" state.

[BTW, DaveM, you don't appear to be explicitly cc'd, so I couldn't
explicitly remove you.  Presumably you are getting this thread through
the linuxppc-dev list.]

Paul.

Re: patchwork states and workflow

[David Miller]

From: Paul Mackerras <paulus@samba.org>
Date: Fri, 19 Sep 2008 15:59:32 -0700

> [BTW, DaveM, you don't appear to be explicitly cc'd, so I couldn't
> explicitly remove you.  Presumably you are getting this thread through
> the linuxppc-dev list.]

Indeed, my bad :)

Re: patchwork states and workflow

[Benjamin Herrenschmidt]

On Fri, 2008-09-19 at 15:59 -0700, Paul Mackerras wrote:
> Kumar Gala writes:
> 
> > I've always been a bit confused about some of the states we can put a  
> > patch in.  For example, what does 'archiving' a patch mean?
> 
> Archiving puts the patch away somewhere where it doesn't appear in the
> normal pages and needs extra effort to get to, as I understand it.
> 
> > What's the difference between 'deferred' and 'rejected'?  Is 'Under  
> > Review' useful?
> 
> Deferred usually means the patch depends on something else that isn't
> upstream, such as patches that only apply against the RT tree.
> Rejected means we just don't want to do what the patch does.
> 
> > My biggest question is how to manage the transition of 'Accepted' and  
> > 'Awaiting Upstream' and having clear definitions of what we think  
> > these mean.
> 
> I put patches into "awaiting upstream" when I put them in a bundle, so
> it means that they have entered my QA process.  When they're in my
> public tree, I put them into "accepted" state.

Note, Kumar, that I have a git hook that will generate a file that
lists the sha1 and corresponding patchwork IDs when you use git-am.

I can send that to you when I'm back.

You can then use a little tool that automatically update patchwork based
on that file, filing the SHA1 reference in the database and switching
the patches to "accepted" state.

Ben.