Re: Commitfest infrastructure (was Re: 8.4 release planning) - Mailing list pgsql-hackers

From Brendan Jurd
Subject Re: Commitfest infrastructure (was Re: 8.4 release planning)
Date
Msg-id 37ed240d0901270729m78ae39d8o6becd4290be6e7f8@mail.gmail.com
Whole thread Raw
In response to Re: Commitfest infrastructure (was Re: 8.4 release planning)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Commitfest infrastructure (was Re: 8.4 release planning)
Re: Commitfest infrastructure (was Re: 8.4 release planning)
List pgsql-hackers
On Wed, Jan 28, 2009 at 1:35 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> I have started some very trivial work around this a while ago with the
>> intent to get something simple up and working before too much bike
>> shedding is done. I'll contact Robert off-list to discuss that. If
>> somebody else - who actively works with what we have now!! - is
>> interested in that discussion, let me know.

I'm very interested in that discussion.  I don't know whether I am
"actively working" with what we have now, but that's because since I
wrote the original template structure, it hasn't changed a whole lot.
Most of the tweaking has had to do with presentation, and massaging
mediawiki to do what we wanted.

As Alvaro points out, the wiki approach was intended to provide a
stop-gap solution to patch tracking, and also to help us identify what
we actually needed from a patch tracker, so that we could make a
sensible decision about which tool to use when we did eventually move
forward.

>>
>> Will obviously take it on-list before any decisions are made. So far I'm
>> just talking about discussing a prototype.
>
> Sounds good.  I think we will have the best chance of success if we
> keep it real simple.  I don't want this to turn into a propaganda war
> about using everyone's favorite tool.  I just want to write down a
> database schema that mimics the organization of the existing wiki
> page, put a thin web interface around it, and call it a day.  It will
> take longer to analyze whether some other tool is sufficiently close
> to that than it will to write a tool that is exactly that.
>

I can understand the desire to avoid a propaganda war.  These
discussions have borne little fruit previously, in part because we
haven't had a clear idea of what was actually required from the tool.

I think the picture has started to become more clear during the 8.4
dev cycle.  Most importantly, there was much ado made about the need
for powerful email integration features in previous discussions.  This
severely restricted our choices (possibly to zero?).  I feel that the
commitfest wiki has demonstrated that no such integration is required.Everyone wants to keep on using the mailing list
fordiscussion, but
 
we need somewhere else to keep track of patches and their status.

To my knowledge, authors have been happy to add patches to the wiki
and reviewers have been happy to update their status with no email
integration whatsoever.  We've continued to discuss things on the
lists, while updating the wiki as required.

If we forget about trying to integrate with email, the field opens
right up and we can use pretty much any just-install-the-package
tracking software out there and it will get the job done.  For the
sake of not advocating my "favourite tool", I won't name any
particular software, but I can think of several off the top of my head
that could mirror the structure we currently have on the wiki without
stretching.

I think it's possible to skip the "roll our own" step in all of this
and just move on to using a ready-made solution.  In reality our
requirements are very simple.  Writing a low-fi version of the wiki
would be pretty easy, but just dropping the patch data we already have
into a patch tracker would be even easier.

Cheers,
BJ


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Patch to add Windows 7 support
Next
From: Andrew Dunstan
Date:
Subject: Re: mingw check hung