Release reviews need to
be scheduled (posted) for the public at least 1 week prior to the event, and the
materials should be readied in advance of the scheduling, since they are part of
the posting along with the date/time/callin number that goes out to the
community.
Some other random bits
of advice from my own experiences:
- Have an email statement from Janet
Campbell stating that your IP log has been reviewed and blessed for release
*in writing* available to show
at the release review. Oral confirmation is not
sufficient.
- In general, the release “deck”
should point back (via URLs) to most of the persistent information – your IP
log, your project plan, Bugzilla, etc. in addition to summarizing them. This
helps to show that you are being transparent and communicative outside the
review per se.
- Project metadata should be up to
date and your website should reflect the release schedule, etc. contained in
the metadata.
- Remember that you need PDF as well
as PPT format for the posting.
- I would separate the release
review into a small number (1-2) of “important” slides and then a larger
number of “backup” slides – no one may ask you to go through history, feature
lists, etc. (though you should have them ready) but you will certainly need to
address issues like IP cleanliness as part of the public
forum.
- I’d suggest you invite some known
adopters or users to attend as advocates and as a demonstration of your
community building and outreach.
From:
eclipse.org-planning-council-bounces@xxxxxxxxxxx
[mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of David M Williams
Sent: Thursday, October 26, 2006
10:08 AM
To:
eclipse.org-planning-council
Subject: Re:
[eclipse.org-planning-council] Questions About Release
Review
> 1. Release
version: although i have milestones for 0.7, does it make sense (according to
Eclipse way) to consider 1.0 version instead of 0.7?
No, I'd
stick with 0.7. Its always easier to go "up" later, rather to go end up having
to go "down" ... if, for example, in the off-chance you decided at some point to
release a 0.9 version instead of a 1.0 version.
And, I'm
just stating a general rule ... nothing specific to your project. We in WTP sort
of did this wrong once in our distant past (and we still hear about it :)
Bjorn
Freeman-Benson <emo@xxxxxxxxxxx>
Sent by:
eclipse.org-planning-council-bounces@xxxxxxxxxxx
10/26/2006 10:38
AM
Please respond
to "eclipse.org-planning-council"
<eclipse.org-planning-council@xxxxxxxxxxx> |
|
To |
yossi@xxxxxxxx
|
cc |
tools-pmc@xxxxxxxxxxx,
"eclipse.org-planning-council"
<eclipse.org-planning-council@xxxxxxxxxxx>
|
Subject |
Re:
[eclipse.org-planning-council] Questions About Release
Review |
|
Yossi,
Your PMC (John and Doug) should
help you prepare for a release review - it is a non-trivial undertaking and I
suggest you start planning as soon as you can. As John noted, the
instructions about Release Reviews are here:
http://www.eclipse.org/projects/dev_process/release-review.php
Yossi
Leon wrote:
Hi
All,
I'm taking Tim's advise and i'm
posting my questions to the planning council:
As project leader i
want to release the PHP IDE till the end of the year (Dec 21st). The current
state is that we're about to release 0.7 Milestone 3.
1. Release
version: although i have milestones for 0.7, does it make sense (according to
Eclipse way) to consider 1.0 version instead of 0.7?
2. Schedule:
How much time before the actual release i need to schedule the release
review?
3. Any other suggestions i should
consider before the release review?
--
_______________________________________________
eclipse.org-planning-council mailing
list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council