New idea for patch tracking

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: New idea for patch tracking
Date: 2007-05-05 02:00:25
Message-ID: 200705050200.l4520Pb07412@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-www

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Attachment Content-Type Size
unknown_filename text/plain 775 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2007-05-05 02:28:52 Re: New idea for patch tracking
Previous Message Bruce Momjian 2007-05-05 01:41:17 Re: Feature freeze progress report

Browse pgsql-www by date

  From Date Subject
Next Message Andrew Dunstan 2007-05-05 02:28:52 Re: New idea for patch tracking
Previous Message Bruce Momjian 2007-05-05 01:41:17 Re: Feature freeze progress report