Hi there!
Cor Nouws wrote:
Kohei Yoshida wrote (8-11-2007 17:06)
On Thu, 2007-11-08 at 16:47 +0100, Bernd Eilers wrote:
Anyhow you certainly don´t want to break that semi-automatic process
to generate Release Notes and volunteer to offer to parse a few
hundred specifications in a few hundred different plain text based
formats
So, is that true that we have a few hundred new features going in to
each release? If that's true, I'd agree for the need of automation but
I have my doubt that that is really the case. Correct me if I'm wrong.
Count for 2.3.0 is only (...) about 70.
http://wiki.services.openoffice.org/wiki/New_Features_2.3#Full_list
Though some structured data/lists were available, it took more that a
day to only discover all features. Some simply had to be dug out
Issuetracker.
And one feature was discovered a month after the release of 2.3.0 :-)
I cannot judge about a specific issue leading to this thread, but the
more automated (= regular info) the better, IMO ;-)
It was just coincidence that I used the URL with the text that kohei
wrote in the Wiki as an potential example for not yet having used the
specification template.
If you look at http://development.openoffice.org/releases/2.3.0.html you
will find dozens of features where we could not get the right/good
information automatically for the last Release (that´s everywhere where
there is a feature-info: in the text). And I think that can only be
improved for our next Release by explaining again how the current semi
automated process works and what one self can do than to help improving
our Release notes.
Rules currently to get better info into the release notes are:
1.) Use either the wiki specification template or the ODT specification
template
2.) Write a feature specification announment in EIS including
issuetracker id and specification URL ( don´t use a "-" as spec URL or
as taskid instead ).
2.1) Make sure the feature tile is "user"-readable and not
"developer"-only information as it will become part of the release notes.
2.2.) In the description of the feature you may include "developer-only"
information as long as you also have a valid specification.
3.) In the first paragraph of the abstract of the specification write a
small text about what is being specified, don´t start the abstract with
text like "This document...." or "This specification " instead .Use
text that you think can go into the release notes, that is use
"user"-readable text for this first paragraph everything else in the
document can contain "developer-only"-readable text.
4.) Check that the spec is usable using EIS / Misc / Check Specification
menu or https://so-web.germany.sun.com/EIS2/guide.CheckSpecification
That´s how the current processes work. But I am of course open to
discuss potential improvements on the program that creates the interim
document used for creating Release Notes, if the need to do so should occur.
Regards,
Cor
Regards,
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
