Re: Postgres tracking - the pgtrack project

Greg Sabino Mullane wrote:
> I've been thinking about this a lot since before the Summit, and the
> only solution I see is to design something specifically for us.
> Rather than get bogged down in details about how it will work and
> what technologies it will be using, I'd like to share my ideas on
> how it will work from an end-user perspective. There's a simple web
> interface. You can use it to get the answer to questions like this:
>
> What are all the open bugs for the current release?
> Who is working on the updateable views patch?
> Which bugs were fixed in 8.1.3?
> What's the feature history of psql since 2003?
> What are some easy TODO items that need getting done?
> Just when does Tom Lane sleep?
> What features were added in 8.1?
> What are the current unapplied patches?
> What bugs were fixed in tsearch2 from version 7.4.5 to 7.4.12?
>
> Yes, maintaining it will be a royal pain in the butt. But my theory has
> been "if you build it, they will come". It will require a lot of human
> interaction, as automation only takes you so far, especially when trying
> to parse mailing list messages. But if we eventually get a decent-size
> group of people who each put in a little work on it, it should be
> quite possible to keep it up to date. (Also, this would be a great way
> for people to help the project who don't have the time and/or skills
> to do coding).
>
> The idea is to allow everything to happen as it already does, e.g. no
> extra burdens for Tom, no extra processes anywhere. However, all the
> existing information is gathered into one centralized and searchable place.
> The primary sources will include the code, the docs, and the mailing lists.
> Especially the mailing lists.
>
> So, rather than go off in a corner and start coding, how about I start a
> pgfoundry project for this and document my existing ideas? Any objections
> to giving this a try?

Good approach. Let me tell you what doesn't work well currently:

What is fixed in current CVS that was not on the TODO list
already, and marked with a dash?
What fixes/bugs are being worked on but not yet in the patch queue?
What are all the features/fixes in each release?

Right now, the release notes show a list of all the significant items in
each release, but it isn't available until the release, and it isn't
complete (because it would be unreadable by ordinary users). And there
is no tracking of individual items in progress except by individual
developers. Magnus, for example, tracks Win32 items, and Tom tracks
backend stuff. I track whatever no one else tracks.

As far as tracking, right now, +50% of items come in and are discussed
via email, not a bug form. How does that information get into a
tracking system without huge extra work? We can do it, and it would
give people nice feedback, but is the effort worth the benefit?

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

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