Tom Lane wrote: > "Greg Sabino Mullane" <[EMAIL PROTECTED]> writes: > > 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. > > Well, nobody's going to accuse you of thinking too small ;-). Sounds > great to me, though, if you think you can pull it off. Have at it! > > > 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? > > [etc] > > That sounds fine for the "output" part of things, but where does the > "input" come from? ISTM that it's been the input side that's been the > real bone of contention in all the discussions of specific tracking > software. > > BTW, another "output" thing you might consider is "having draft release > notes ready-to-go on demand". Currently, Bruce prepares the release > notes on the basis of a very tedious scan of the CVS commit logs.
Having an intermediate release note list, beyond the dashed TODO items, might be helpful. So the idea is to track work in progress, and completed items. The question is always whether the effort is worth the benefit. We can try and see how it works. > If this sort of stuff were being dropped into a tracker as it went > into the CVS tree, at least the research part of making the notes would > be zero-effort (or perhaps better to say that the work would be spread > out instead of concentrated). Well, multiple commits often end up as a single entry (and many commits don't need to show up in the release notes), so the tracker would just give me a backup when creating the release notes. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
