Re: small but useful patches for text search

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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