Re: Commit fest queue

(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 <stark(at)enterprisedb(dot)com> 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