On May 5, 2007, at 11:40 AM, Dave Page wrote:
<snip tracker outline>
Barring a few trivial details, that sounds almost identical to
Well, Andrew says everyone he talks to doesn't want it. They want a
more comprehensive solution that goes from bug to patch.
I don't recall him saying that, though I do know that's /his/
opinion. It's certainly *not* the opinion of most of the people
I've spoken with.
I don't disagree with the idea in principle though, but I don't
believe it will work for us because it's so fundamentally different
from the way we currently work and still wouldn't solve the problem
of capturing all the relevant discussion regarding a given patch
(or bug) without a reasonable amount of manual work, or grafting a
large part of what I'm proposing on the side.
IIRC, every recent debate about going to a bug/issue (and now patch)
tracker has ultimately boiled down to the impact it would have on our
current work processes: it has to work 100% painlessly off of the
mailing lists. It's got to do more than just pipe changes to the
mailing list; it's got to be able to be driven by the list as well.
That's the real challenging part.
People have suggested different trackers that have varying amounts of
email capability, but I don't think any of them have had the full
capability that we'd need. At best they might accept comments on a
bug/issue via email, but to work for the community they'd need to go
beyond that. You'd have to be able to resolve via email (preferably
tied to -commiters). You'd need to be able to make a bug as invalid.
You'd need to be able to open a new issue via email. And change
status. And assign it to someone. And it would have to actually
thread discussion to be useful. Probably some other things as well.
Since a system like that doesn't exist I think it's going to be up to
us to create one. When it comes to the full set of features you'd
expect out of an issue tracker, it would probably make sense to start
with an existing project and try and add this functionality. But
right now I don't think such an effort would work well, because we
don't know well enough how all these new features should work.
But writing a patch tracker would be simpler than a full issue
tracker. It's also something we could more easily do in a piece-meal
fashion, since the only users will be developers. Building such a
tool would provide a wealth of experience that could then be applied
to tackling a full-blown issue tracking system.
The system Bruce and Dave have outlined shouldn't be terribly hard to
implement. Let's start with that and see what we learn (as I've
already told Dave, this is something I'll help with). Otherwise we'll
once again have spent another chunk of community effort on a tracker
discussion that results in nothing being done (I guess it has been 6
months since it was last brought up, so we were due again anyway...)
Jim Nasby [EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly