Managing patches against upstream?
Joshua Judson Rosen
rozzin at geekspace.com
Fri Jul 18 15:56:54 EDT 2014
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?
--
"'tis an ill wind that blows no minds."
More information about the gnhlug-discuss
mailing list