Re: Feature freeze progress report

From: Dave Page <dpage(at)postgresql(dot)org>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Feature freeze progress report
Date: 2007-05-01 07:56:15
Message-ID: 4636F29F.8000001@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-www

Bruce Momjian wrote:
>
> Sounds interesting, but I am not sure how that is going to track
> multiple versions of the patch,

They could easily be submitted through the web interface as revisions to
the original version.

> or changes in the email subject.

We'd need to keep the reference number in there, but other than that it
could change. We could also examine the in-reply-to header of every
email and attach based on that, but I'm not sure that's necessary.

> The bottom line is that there is a lot of thinking that the patch queue
> is so large because no one knows what to do. "Oh, if we were better
> communicators, more would be done". The patch queue is large because we
> have lots of March 31 patches, and because we don't have enough people
> to review them quickly.

Thats is true, but there are also patches in there that have been there
for quite some time adn have had little or no feedback. Consider
Heikki's grouped index items patch
(http://momjian.us/mhonarc/patches/msg00032.html). That thread starts on
7th March when he posted an update because the old one had bitrotted.
There are six messages in the thread on the patch queue, four of which
say "message no available", and the last means little without the
preceeding messages.

When a committer comes to look at this, if he's not sure of something
he's going to be wasting time searching the archives to find all the
different thread fragments that make up the various discussions on the
topic, and those related to each individual revision of the patch. That
has got to be part of what makes reviewing patches both hard, and
uninteresting work. If we can make it easier and quicker, even with just
the current committers we might have found that one of you were able
(and keen) to review much more quickly.

> The people who have expressed interest in reviewing patches already know
> where we stand on the patches, and a status email of where we are each
> patch will be posted shortly. I just can't do it this time because I am
> traveling.

This is precisely the sort of trivial task that I believe we can make
much easier for you, if not eliminate altogether.

> If you want to try a tracking system, go ahead, just pull from the
> patches email list, and somehow try to grab discussion from
> hackers/patches on this patches, and give a way to manually update the
> patch status via a web site.

OK, I will give it some thought. Obviously I'm not going to do much more
before release though.

> If your system works, I will not need to
> maintain a separate patches queue, but I will keep doing it until we
> know the web site idea will work, just in case.
>

I would expect nothing less :-)

Regards, Dave.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2007-05-01 08:11:42 Re: Fwd: [PATCHES] Preliminary GSSAPI Patches
Previous Message Gregory Stark 2007-05-01 01:54:28 Re: Feature freeze progress report

Browse pgsql-www by date

  From Date Subject
Next Message Jim Nasby 2007-05-01 12:27:40 Re: Feature freeze progress report
Previous Message Bruce Momjian 2007-04-30 22:25:04 Re: Feature freeze progress report