From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] proposal: a patch acceptance system In-Reply-To: Your message of "Sun, 02 Nov 2003 10:01:54 MST." From: "Russ Cox" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <60449.1067804605.1@t40.swtch.com> Message-Id: Date: Sun, 2 Nov 2003 15:23:25 -0500 Topicbox-Message-UUID: 7c1a3ea6-eacc-11e9-9e20-41e7f4b1d025 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