1. YHi Tou
create the IP log yourself from
information about your 3rd party usage, contribution
questionnaire
history, etc. You can see the WTP one here: http://www.eclipse.org/webtools/development/ip_log.html.
The best thing to do is to link it from your web pages, so that it’s
public/transparent and then all you have to do is include the URL in
your
release review and have Janet (EMO legal counsel for IP matters)
certify it.
2. Project
metadata drives the
construction of pages like http://www.eclipse.org/projects/
by providing information to PHP scripts that formulate it into HTML in
various
parts of the Eclipse.org website. This is placed in a directory in your
web
arena in CVS called “project-info”. The easiest way to set it up is
to take another project’s version and copy/modify it for yours (though
you might want to look at a couple of them to make sure you’re seeing
all
the options). I believe Bjorn is the knowledge center for this, but I
suspect
you can quickly clone something that will satisfy the basic needs.
Sorry for
the delay…was on vacation,
and having trouble grinding through the thousands of emails that
accumulated…
Best,
-t
1. How do i get/create
the IP log?
2. What do you mean by
"Project metadata"?
--
Yossi Leon, Product
Manager, Development Tools & PHP IDE
Project Leader
yossi@xxxxxxxx http://www.zend.com/
+972-3-6139665 ext.229
From:
eclipse.org-planning-council-bounces@xxxxxxxxxxx
[mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of Tim Wagner
Sent: Thursday,
October 26, 2006
6:37 PM
To:
eclipse.org-planning-council
Subject: RE:
[eclipse.org-planning-council] Questions About Release Review
-->
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.
> 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 :)
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
