Managing patches against upstream?

[Bruce Dawson]

I can offer some probabilities of what those status would mean to a
tracking system. But I don't know their precise meaning in Patchwork.
These are pretty obvious, I don't mean to offend - just thought I'd
include them rather than go through another email transaction. 

New
	Its a new patch.
>      Under Review
	The patch is under review. Typically awaiting testing.
>      Accepted
	The patch is accepted and waiting to go through the release process.
>      Rejected
	The patch is rejected - the reason should be in a separate field. 
>      RFC
	The RFC's associated with the patch - typically compliance. Sometimes clarification in the RFC is needed.
>      Not Applicable
	The patch does not apply to the series of patches (typically for distributions or H/W configs)
>      Changes Requested
	Changes to the patch have been requested (typically by vetted community members)
>      Awaiting Upstream
	The patch can't be accepted until something happens in the upstream code. (The "something" is typically described in another field.)
>      Superseded
	The patch has been superseded by another patch. Meaning: This patch won't be distributed.
>      Deferred
	The patch is being delayed - the reason *should* be explained in a separate field.

--Bruce

On Fri, 2014-07-18 at 15:56 -0400, Joshua Judson Rosen wrote:
> Have any of you ever used Patchwork <http://jk.ozlabs.org/projects/patchwork/>
> or other patch-tracking systems?
> 
> I can't seem to find documentation on what the various patch-states
> that it uses are actually supposed to mean; can you perhaps offer
> some interpretation of these?
> 
>      New
>      Under Review
>      Accepted
>      Rejected
>      RFC
>      Not Applicable
>      Changes Requested
>      Awaiting Upstream
>      Superseded
>      Deferred
> 
> ?
> 
> 
> Some background...:
> 
> I've been thinking a lot about patch-tracking at work, recently:
> we're doing embedded Linux projects, and we've got a fair amount
> of technical debt on our backlog in the form of patches that have
> yet to be merged or released upstream, and I'm basically trying
> to get that under control--the first issue being to just find an
> effective way of keeping track of the patches and what state
> they're in with regard to upstream acceptance (and how close we are
> to being able to drop the patches and `clear the debt from our ledger'--
> since one of the most fundamental mistakes one can make when dealing
> with any kind of debt is to lose track of it).
> 
> The options that I'm mulling over right now are basically to implement
> a "Patch" tracker (with appropriate Statuses) in our local Redmine
> system, and/or deploy something like Patchwork to sit between the
> internal team and the various upstream mailing lists. I can go into
> more detail on that if anyone's interested, but I'm really just
> trying to come up with a list of statuses and what they mean right now.
> 
> I'm really only barely familiar with Patchwork right now, and it
> seems like probably I should start by trying to apply its stock
> set of statuses (apparently they work for other people, like
> OpenEmbedded and OpenWrt), but I'm just not finding any documentation
> and the meanings of some of the status-names are just... not clear
> to me.
> 
> Guidance?
>