1. You 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
From:
eclipse.org-planning-council-bounces@xxxxxxxxxxx
[mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of Yossi Leon
Sent: Wednesday, November 15, 2006
11:47 PM
To: eclipse.org-planning-council
Subject: RE:
[eclipse.org-planning-council] Questions About Release Review
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.
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