Bruce Momjian wrote:
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,
I will say publicly what I have said to others privately. Forgive me if
I'm a bit blunter than usual. I do not see any value in this at all.
What we need to track are problems to be solved, be they bugs or
features, not particular patches. Tracking patches simply comes too late
in the process.
I think that your attitude to the use of bug/feature trackers is quite
unreasonable, and certainly in opposition to what seems to be the
majority opinion among developers. It's a great pity that you are so
utterly resistant to use of tracking software. The only reason that this
system, at best a half measure in almost everyone's eyes, is being
proposed, as far as I can see, is that you will not agree to use
anything else.
So if this goes ahead and proves to be of little value, I hope that you
will relent and agree the use of proper tracking software like almost
every other open source project uses. It really is time that PostgreSQL
managed to advance beyond thinking that email lists are the greatest
management tool since sliced bread. It's just indefensible in 2007.
cheers
a disappointed andrew
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
