Frank Schönheit - Sun Microsystems Germany wrote:
Hi Mathias,
Hi Frank & all,
At the risk of being caught ignorant: should feature/changes mails on
these lists be posted before the CWS is approved? I think that odds
aren't low that something might get changed after handing over the CWS,
especially in case of new developers.
AFAIK policies require mails to be sent when the CWS does to QA - which
in fact might not make that much sense.
Perhaps we can distinguish between "preliminary" and "final"
announcements, the former is sent when the CWS is handed over from the
developer, the latter when the final step ends with the CWS approval.
Currently we do only have "final" announcements. What´s important to
consider is that text from the feature mail gets into the ReleaseNotes
if no specification is there by a semi-automatic process looking at
information in EIS and in specifications and generating a document which
is the basis for the ReleaseNotes.
So it´s currently an unfortunate situation that when a feature changes
after the feature mail has been send nothing can be done about the entry
for it in the database and we might end up with wrong information in the
ReleaseNotes.
So having correct information in the release notes requires that the
featuremail information can be changed or is "final" from the beginning.
On the other hand the open source philosophy is to publish early and to
publish often. This has the advantage of bringing all possible
stakeholders ( eg. QA, documentation, UX, code reviewers etc. ) on board
as early as possible.
IMHO having two stati for feature mail and api-announcements would be a
good solution to resolv the conflict. For personal taste I would name
the non-final one "draft" instead of "preliminary" but that´s just a
minor issue ;-)
I'd prefer an ability to add feature mails in EIS which are not yet
sent. That is, I would like to fill out the form for the feature mail,
and press some "Send Later" button. The mail would then be associated
with the CWS, and only sent when the CWS gets
approved/nominated/integrated (whatever). QA can still look at the
mails, and development can change them before sending, if necessary.
Since a few days we have already association of the feature mails with
the CWS via the taskid and the task list in the CWS overview page.
There is a new column featuremail and also an new column specification
in the task list with links to featuremails and specifications.
There also is already a feature in EIS to resend a featuremail or
apichange, which is currently used only if there was a network error or
similar and it is currently only available in the list of featuremails
or apichanges.
So IMHO what we need is to make the featuremails/apichanges editable,
offer the resend featuremail/apichange directly on the page where you
can edit it and add a status flag for "draft" and "final" which would
not only be shown in the featuremail/apichange but also be available in
the Task list of the CWS overview page where you can find the link to
the featuremail. For apichanges we would also need a new feature in EIS
to associate the list of apichanges with the CWS.
The additional advantage of such a feature - completely independent form
the current discussion here - is that for large CWS, you do not need to
manually track all the chances (esp. API changes) you did therein. You
can write them when they happen, and they're all sent at once when the
CWS is finished.
We could discuss wether featuremails/api changes should be send as mail
only when the status moved to finished or wether to send the first draft
as mail also. I personally do like the idea much to have information
available as soon as it´s there, for those who are interested. Well if
the change did happen and you´ve written about it and you´ve also
declared that the information is currently only in draft status there is
IMHO no reason to hold back that information, so possible stakeholders
can already start to prepare their todo list to be worked on after the
momment that the final announcment is there. Therefor I like the idea
that Joerg presented to have an RSS feed for featuremails and
apichanges, which would contain last recently edited featuremails or
apichanges. On the other hand RSS feeds may be not yet a widely accepted
medium for everyone so I would like to suggest to keep the mails for the
final status and add the RSS feeds for those who would want to get in
touch with the information and updates to it earlier. Keeping track only
for yourself without making information also available for others would
not be possible with such feature but it would allow to keep track and
allow others to see what is about to be there in the future early also.
The questions where I am currently unsure about are the following:
1.) can automatically move all featuremails/api-changes from state draft
to state finished when the state of the CWS moves to state 'ready for
QA' or should we do that when the state of the CWS moves to 'integrated'
or if should we not do any automation at all and leave it up to the
developer to change the state of the featuremail and apichange only?
2.) Can there be a case where a feature mail is "finshed" but must still
be changed and what should happen in this case regarding the
mailinglist, resend the featuremail?
If for 1.) we would decide to declare things final only at integration
Problem 2.) is not there because a change in the feature would be done
in a new CWS and a new featuremail would be needed there for it. On the
other hand QA must have information about the feature when the CWS is
'ready for QA' and we can not require that anyone in QA get´s familar
with RSS feeds. Maybe this can be resolved by having 3 states 'draft',
'published' and 'final' and moving to published with sending to
mailinglist when state changes to 'ready for QA' and moving to
'finished' with or without publishing to mailinglist also when CWS state
changes to 'nominated'.
Ciao
Frank
Ciao,
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
