Re: [9fans] proposal: a patch acceptance system

["Russ Cox" <rsc@swtch.com>]

The main problem with the current system (email 9trouble) is that
the reading of 9trouble itself is spotty.  But if we end up with a
different patch submission system there's no reason to believe the
problem would go away.  I was reading 9trouble pretty regularly
before the summer, but then it got away from me.  Dave has been
keeping up pretty well otherwise.

When we don't like a patch, we reply and tell you.  If you're not
getting replies it means we're behind.  There's still a lot of good
stuff sitting in the 9trouble box that I just have never gotten to.
I think what you're trying to address is the not knowing whether
we're busy or we silently deleted your bad idea.  But we don't silently
delete bad ideas.  It just seems that way since we get behind sometimes.

I don't think the code drift is too big a concern.  If you include
in the files the copy you are changing, then it's no big deal to
generate the diffs and apply them to the current file.
Your solution of checking for patches every time you update
a file isn't accurate -- we make the changes in our local
tree and then eventually they make it to sources.

It sounds like more than anything else what you want is a way to
check on your submitted changes, which is entirely reasonable.

Sitting on the other side of the fence, I want an easy way to
accept patches, basically a button to push when I think it's good
that will apply the change.  And when they're not good, I want
an easy way to send people back to the drawing board with
constructive comments (like, "make the code style look like all the
other code so your patch doesn't stick out like a sore thumb",
though that hasn't happened recently).

I built a simple patch tracking system based on your proposal.
Let's see how it works.  See patch(1).

Russ