Robert Haas wrote: > Oh, I'm not objecting to email as a way of communicating. I think a > bug tracking system or web forums would increase the amount of effort > required to keep up to date on what is going on, and I can't imagine > what the corresponding advantage would be. What I don't like is the > use of email as an *organizational* tool, because (even with Google) > it's hard to go back to a pile of email and fish out the items that > are still relevant. If there's a list of things that need to be put > into the release notes or a list of things that need to be done by 8.4 > or a list of patches that need to be reviewed, I think it makes sense > to have an explicit list of some kind. > > I think there is near-universal agreement that the CommitFest wiki has > been very succesful. I've certainly spent a lot of time keeping it up > to date, which wouldn't have been possible with the old system, and I > at least find it much easier to refer to. I don't see why the same > thing couldn't be done with release notes. Heikki asked this week > where he should document an item to mentioned in the release notes, > and the answer was in the CVS commit message. If the answer had been, > in a wiki page, he wouldn't have minded, and if we did that > consistently for a whole release cycle, it would probably save you > quite a bit of time finding everything again at the end. Or so it > seems to me; but I might be wrong.
Collecting the release note items takes less than a day; it takes 5-6 days to research and reword them all to make a consistent set of release notes. I don't see how pushing the burden of release _item_ tracking to every committer is going to significantly reduce the job of creating the release notes. I can see it increasing the burden on the community. Remember the audience for a commit message (backend technical) is not the same as the for release notes (end user), so you would have to educate everyone and make sure they are all consistent. > > I think the example of moving the TODO list to a wiki, that was supposed > > to relive a lot of the burden I carry to maintain the TODO list, has > > really not affected my workload much, which kind of reinforces the > > feeling that our existing setup is probably the best we are going to do. > > Of course, the commit fest wikis have helped, so I guess there is room > > for improvement in some places. > > Well, the TODO list, because it's traditionally been filtered by you, > carries the implication that the items therein are not just any old > thing that's been suggested by someone, but things where there was > some level agreement (from you, if not from anyone else, but that > carries some weight all by itself) that they might be worthwhile. > Maybe that wasn't your intention, but I think people see it that way > to some degree. It was not my intention. Once an item gets a concensus community opinion, I add it to the TODO list, and hopefully others can as well. > My concern with the list of outstanding items for 8.4 based on a quick > look is that I think many of those things are not, in fact, > outstanding items for 8.4, and those that are may not be important > enough to hold up beta for. Now since I haven't read through them all > yet, I'm not 100% sure of that, but that's my concern for what it's > worth. Certainly not all are valid, and some are things we _should_ fix for 8.4, even if not necessary, but again it is based on time and manpower, but again, once the release notes are done I can focus on the list. Hopefully the emails will jog people's memory that we do have some open stuff. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers