I have already responded to all the email comments. Here is my idea of
moving forward. There are basically three interrelated issues:
1) bug tracking
2) getting more people to review complex patches
3) patch tracking
I am not going to go into #1, except to say that the problem has always
been the effort needed to track the bugs vs. the value.
I am not going to go into #2, except to say that this is going to require
a personal approach to assisting developers. One thing I am going to do
is to add an item to the developer's FAQ outlining how patches are analyzed
for application, which should help both patch submitters and committers
(sample attached).
As for #3, again, I don't want us to take on a burdensome patch tracking
process that is more effort than it is worth, and the lack of people
jumping to even manage a simple web page for current 8.3 patches has me
questioning what kind of support a burdensome tracking system would
receive.
What I think we can do simply is to have our email software automatically
number emails submitted to the patches list that already don't have a
number. This way, all followups, even if moved to the hackers list, would
maintain that patch number, and if an updated version is posted, the user
would keep the same number in the email subject.
Once that is done, it should be trivial to write a web application that
will track the patches based on the subject line, something like
"PATCH#555". Committers can include that patch string in the commit
message, so committed patches can be automatically removed from the open
patch queue. The only tricky part is to handle patches that are rejected
or kept for a later release. That would probably require web access to
adjust.
One thing that has always bothered me about tracking patches is that when
an email to the patches list is bounced for discussion to the hackers
list, there isn't any good way for outside people to track the full patch
discussion because we don't track threads that move to different mailing
lists. The special patch number would make such tracking easier.
The good thing about such a simple system is that it has a very light
burden on patch submitters and committers. The major work is done by the
web application, but that can all be programmed.
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Patch committers check several things before applying a patch:
1) Follows the SQL standard or community agreed-upon behavior
2) Style merges seamlessly into the surrounding code
3) Written as simply and efficiently as possible
4) Uses the available PostgreSQL subsystems properly
5) Contains sufficient comments
6) Contains code that works on all supported operating systems
7) Has proper documentation
8) Passes all regression tests
9) Behaves as expected, even under unusual cirumstances
10) Contains no reliability risks
11) Does not overly complicate the source code
12) If performance-related, it should have a measureable performance benefit
13) Is of sufficient usefulness to the average PostgreSQL user
14) Follows existing PostgreSQL coding standards
---------------------------(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
