Re: New idea for patch tracking

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