Frank Schönheit - Sun Microsystems Germany wrote:
Hi Bernd,
Hi Frank,
Well yes it´s a rather simple algorithm and well normally your
expectation would be right that in this case the text from the first
paragraph of the abstract would be used. But well here it´s special. The
spec document has been changed in a way that the abstract can not be
extracted anymore because ...
Okay, but in general re-using specifications (which IMO makes a lot of
sense) means the generated release notes are wrong, correct?
Making sense is such a relative thing ;-)
Looking into the allfeatures mailing list (did I already say "kudos to
you" for working around collab.net's bug, so this list now works,
again?), of the last 10 feature mails, 8 contained a specification link,
where 5 referred to older-and-extended specs (including the broken one).
Means that half of the auto-generated release notes is wrong.
Interesting argument.
Hmm, we
should improve on this. I suppose that *first* using the mail, *then*
using the spec, as already suggested here, could help.
Well the *then* using the spec is kind of not really an option.
See what we have is the MasterWorkspace and Milestone of a last release
eg. something like SRC680m122 and the MasterWorkspace and Milestone of
the new release eg. something like SRC680m230. Where we can get from
there is to query the EIS database for Childworkspaces integrated
between those versions. Having this list we can query EIS again for
which tasks have been fixed on these ChildWorkspaces. From there we can
query the Feature-Announcement Database for feature mails containing
those taskids. From there - and only from there - we can get to
corresponding specifications. There´s no path to the specification
without the feature mail and thus a fallback to use the specification if
no feature mail is there is not possible. The only possible and really
very rare case fallback szenario here would be to fallback to the text
in the specification abstract if the feature mail did not contain a
description but did contain a spec link. Which leaves us with the
suggestion to just use the feature mail only than. I am open for
changing that semi-automated release notes creation process to do
something like that if we can come up with a clever way that everyone
can agree on on how to extract only a short user relevant information
for the release notes and not copying tons of text from feature mails to
it. Maybe something along the lines of the first pargraph only is always
for the release notes or similar.
Ciao
Frank
Ciao,
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
