From: Josh Berkus <josh@agliodbs.com>
Organization: PostgreSQL @ Sun
To: pgsql-hackers@postgresql.org
Subject: Re: Feature freeze progress report
Date: Wed, 2 May 2007 11:09:01 -0700
User-Agent: KMail/1.8.2
References: <200705021044.l42AiCJ20657@momjian.us>
In-Reply-To: <200705021044.l42AiCJ20657@momjian.us>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200705021109.01576.josh@agliodbs.com>

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