Re: Feature freeze progress report - Mailing list pgsql-hackers

Josh Berkus wrote:
> 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?

No, I think it will be more work than benefit, and Tom and I will still
be doing the bulk of it, so we will have something pretty but more work
for people who are already too busy.

> ====================
> 
> > 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.

This is so funny, I don't know how to respond, only to ask if Dtrace  
will help us here.  ;-)  I admit having such a system would improve the
chances of commercial help by a miniscule percentage, but the cost to
patch submitters/managers is so high in proportion to be humorous.

We have _ample_ evidence that the problem is lack of people able to
review patches, and yet there is this discussion to track patches
better.  It reminds me of someone who has lost their keys in an alley,
but is looking for them in the street because the light is better there.

To be more concrete, during normal development, we seem to have no
problem keeping track of patches, so it is only during feature freeze
that it is a problem.  Now, everyone admits that having patches tracked
on a web interface is going to be more work for patch managers and
importantly also patch submitters.  So do we do the web work just so we
can have a more orderly feature freeze, or do we just accept that Tom is
going to have to post a summary of where we are on patches periodically
during feature freeze and not do the web work for every patch?

I have added a link on the patches queue so you can download the emails
in mbox format.  If someone wants to take that and make a nice web site
out of it and keep that up-to-date during our feature freeze period,
that would probably help. (I can even point the patch queue to a new
URL.)  If no one is willing to do it, I question how much help we would
get with a web patch system.

Heck, if I was around, I would throw up a txt file on the web (using
txt2html) with the status of each patch and keep it current.  I think I
have done that for some past releases.  Why doesn't someone do that and
see how it goes?  Thanks to Tom, you know have a current status of each
patch and who is supposed to work on it.

I am not anti-big-solution, but I don't want a big solution if it isn't
going to help.  If no one is doing even a trivial solution, I don't want
to try a big one.

Get rid of gborg and let's talk.

Why am I having to spend hours in Syndey saying the same thing?  Why
don't you guys go ahead and change things, and when they fail, I will
still be around.

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +