Bruce, all,
> No, my point is that 100% information is already available by looking at
> email archives. What we need is a short description of where we are on
> each patch --- that is a manual process, not something that can be
> automated.
>
> Tom has posted it --- tell me how we will get such a list in an
> automated manner.
Several of us have already suggested a method. If we want the information to
be up-to-date, then the patch manager, or bug tracker, needs to be a required
part of the approval & application process, NOT an optional accessory. That
is, if patches & bug fixes can come in, get modified, get approved & applied
entirely on pgsql-patches or pgsql-bugs without ever touching the tracker
tool, then the tracker tool will be permanently out of date and useless.
It's going to require the people who are doing the majority of the bug hunting
& patch review to change the way they work, with the idea that any extra time
associated with the new tool will be offset by being able to spread the work
more and having information easy to find later, for you as well as others.
Tom seems to be willing; are you?
====================
> Status: Will be rejected unless race conditions are fixed. Needs
> performance testing.
> Discussions: <links to mail threads, like in the current patch queue>
... this brings up another reason we could use a tracker. I now have access
to a performance testing lab and staff. However, these people are NOT going
to follow 3 different high-traffic mailing lists in order to keep up with
which patches to test. As a result, they haven't done much testing of 8.3
patches; they're depenant on me to keep them updated on new patch versions
and known issues and I'm on the road a lot.
If I had a web tool I could point them to where they could simply download the
current version of the patch, test, and comment a report, we'd get a LOT more
useful performance feedback from Sun. I suspect the same is true of Unisys.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco