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: