(I've already said that I think the wiki is a great step forward, FWIW, and I'm not in any way suggesting that we should just drop it and pick my favorite issue tracker or anything. However, for those interested in discussion about theoretical benefits and cons of the different systems...)
On Fri, Apr 11, 2008 at 8:14 PM, Gregory Stark <[EMAIL PROTECTED]> wrote: > For the umpteenth time bug trackers *still* require someone to maintain the > list. It's more structured which is great if it matches the structure you > want, but it still requires someone to go open bugs when a bug is reported by > email, close bogus bugs or bugs fixed via collateral damage, update bugs when > discussions happen on the list about them, etc. Perhaps I wasn't clear. I was describing the specific case where a patch submitter would be required by project policy to submit a patch to a tracker of some kind before discussing it on the list. So there wouldn't be much of an opportunity for those to fall through. And owners of a particular patch would be expected to keep them up to date re discussions. I wasn't discussing emailed bug reports. The problem with a tracker is that it will give you a list of every damn thing that people have put in there, and the data in there can stagnate. The problem with manually maintained lists is that stuff might not get on there at all. What I and at least one other person have tried to say is that the problem of dead issues needing to be closed is a much easier problem to deal with than the problem of an issue not being there at all. Heck, *I* could trawl a tracker and email authors of seemingly dead patches. But there's no way I could maintain a patch list manually without following each and every discussion. > I've seen no discussion about the structure the various bug trackers use and > which would match better with our processes. *That* would be the only useful > discussion to be having. What attributes do you think patch submissions have, > what is the workflow which sets which attributes at which time, who is > involved in which step of this workflow? Etc. Well, I do recall reading at least one thread (not terribly recently) discussing people's favourite trackers, but IIRC it turned into something similar to what happens when we discuss CVS replacements :) > Proposing specific tools without a consensus on what that process is putting > the cart before the horse. You pick the tools to fit what you want to do. We > haven't decided what we want to do yet. This is true. But your processes get shaped by your tools, too. Our processes might be shaped by what we've got, and so continue forever. There should be some awareness of what else is out there. An example of this is the way code flows around the Linux kernel. I'm not for a minute advocating their general structure, but git seems a far better tool than the combination of CVS and emailing patches. Patch announcements aren't always "here's the patch" as much as "please pull from over here". Their tool support seems rather better than ours. And it's changed the way they work. Cheers Tom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
