Re: patchwork states and workflow
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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: patchwork states and workflow
From: Paul Mackerras <[EMAIL PROTECTED]> 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 :) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: patchwork states and workflow
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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: patchwork states and workflow
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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
patchwork states and workflow
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
