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 <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
