public inbox for [email protected]  
help / color / mirror / Atom feed
From: Tatsuo Ishii <[email protected]>
To: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Subject: Re: 7.4 compatibility question
Date: Sat, 25 Oct 2003 09:44:03 +0900 (JST)
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <1066804676.371.92.camel@tokyo>
	<[email protected]>

> I've been pushing this agenda for a few releases now, but some people have
> been, er, boycotting it.  I think, too, that release notes *must* be
> written incrementally at the same time that the feature change is made.
> This is the only way we can get accurate and complete release notes, and
> the descriptions could even include some context, some motivations, etc.
> We have release cycles of 10 months, and there is no way we can make
> sensible release notes by gathering individual commit messages over that
> period of time.  Heck, ECPG has a full Informix compatibility mode and
> there is no mention of that anywhere, because there was no commit "Add
> Informix mode."
> 
> I suggest we just do it like the documentation:  If you don't document it,
> it doesn't exist.  If you don't write a line for the release notes, it
> doesn't exist either.

I tend to agree it. For every release I and my colleague have been
working on creating detailed release notes (of course in Japanese),
otherwise we cannot tell people what are changed, added or fixed since
there is little info in the official release note. This is painful
since we have to dig into the mail archives and cvs commit messages to
look for what each item of the official release note actually
means. These work take at least 2 to 3 weeks with several people
involved. The hardest part is what are fixed. The only useful
information seems to be the cvs commit messages, however typical
messages are something like "see recent discussions in the mail
archive for more details". This is not very helpful at least for
me. Once I proposed that we add a sequence number to each mail and the
commit messages point to the number. This way we could easily trace
what are the bug report and what are the actual intention for the
fix. For some reason noboy was interested in. Maybe this is due to
"coulture gap"... (In Japan giving a sequence number to each mail in
mailing lists is quite common).
--
Tatsuo Ishii



view thread (60+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: 7.4 compatibility question
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox