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