Etienne,
Note that a project/component doesn’t have to be on “the
train” in order to have a Galileo release, i.e. release at the same time
as the Galileo train. The Papyrus team should take a look at the requirements
for participating in the release train (see http://wiki.eclipse.org/Galileo_Simultaneous_Release)
and make a decision as to whether it would be feasible for Papyrus to be
included. In particular, note that by January 5 (for M4+3 projects) the
following requirements must be met:
Projects must have stated and demonstrated their intent to
join Galileo by the M4+0 date. Projects do so by adding themselves to the
table/list above, by signing off each milestone/RC on the Galileo/Signoffs page, and by contributing
appropriate build contribution.
Projects must have an project plan in XML format.
At least one person from each project must subscribe to
cross-project bug inbox, i.e. edit Bugzilla prefs to watch
"cross-project.inbox@xxxxxxxxxxx". Build team members (or their
designated alternates) from each project will provide communication channels:
phone, mail, IM, IRC and will be available during the milestone integration
periods.
Project representatives must attend the planning meetings
and conference calls - you have to be involved to be involved.
Projects must use Eclipse message bundles unless there are
technical reasons not to. (see Message Bundle Conversion Tool and [1])
Projects must use signed plugins
using the Eclipse certificate. Exceptions must be authorized by the planning
council for technical reasons.
Projects must have build process maturity: scripted,
repeatable, and executable by others.
Any new third-party plug-ins that are common between
projects must be consumed via Orbit; the final Galileo release will
not have duplicate third-party libraries (note that this only applies to
identical versions of the libraries; thus if project A requires foo.jar 1.6 and
project B uses foo.jar 1.7, that's ok).
Projects must optimize their own update site using pack200 to reduce
bandwidth utilization and provide a better update experience for users. With
the introduction of p2, project update sites must generate metadata (artifact
and content repository info).
I’d be happy to help with this, in any way I can, if you
decide that you want to be on the train.
Cheers,
Kenn
Hussey
Program Manager, Modeling and Design Solutions
![[Embarcadero Technologies Logo]](jpgmJNdq2PXzH.jpg)
Embarcadero Technologies, Inc. | www.embarcadero.com
82
Peter Street, Second Floor |
Toronto, ON M5V
2G5
Kenn.Hussey@xxxxxxxxxxxxxxx
Office:
416-593-1585 x9296 Mobile:
613-301-9105
From: mdt-papyrus.dev-bounces@xxxxxxxxxxx
[mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] On Behalf Of Etienne Juliot
Sent: Friday, November 07, 2008 8:08 AM
To: Papyrus Project list
Subject: [mdt-papyrus.dev] [Fwd: RE: [modeling-pmc] Project planning]
Just for information.
Today, Papyrus isn't identified to be include in Galileo.
I think it's normal because no beta version is still available, and we don't
have a clean roadmap. But if we want to propose a first version for Galileo, we
need to discuss with Kenn before the end of December to choice to target or not
Eclipse 3.5.
todo ....
-------- Message original --------
I did a rolled-up plan for MDT - see http://www.eclipse.org/projects/project-plan.php?projectid=modeling.mdt. I'm not how easy it would be to automate a roll-up like this, but it was easy to put together. It also helped us to achieve consistent themes among the MDT components...
Kenn Hussey
Program Manager, Modeling and Design Solutions
Embarcadero Technologies, Inc. | www.embarcadero.com
82 Peter Street, Second Floor | Toronto, ON M5V 2G5
Kenn.Hussey@xxxxxxxxxxxxxxx
Mobile: 613-301-9105
-----Original Message-----
From: modeling-pmc-bounces@xxxxxxxxxxx [mailto:modeling-pmc-bounces@xxxxxxxxxxx] On Behalf Of Ed Merks
Sent: Tuesday, September 30, 2008 10:11 AM
To: PMC members mailing list
Subject: Re: [modeling-pmc] Project planning
Rich,
I'm not sure it's a rule or a guideline. :-P I just wanted to be sure
that the things I for which I'm directly responsible, EMF Core, SDO, and
XSD, did things in a consistent way. Kenn asked for this flag for MDT,
and that's where XSD lives, so I wanted to follow this same convention
for EMF Core and SDO. As a result, I also wanted all the EMF and EMFT
components to be consistent with that as well. It seems like a pretty
sound approach and no one complained!
I'm not doing a rolled up EMF or EMFT plan because I was hoping that
whatever technology is developed to roll up plans could also be used to
roll up the various EMF and EMFT component plans into rolled up plans,
then recursively to create a modeling project rolled up plan, and
finally an overall Eclipse plan...
Richard Gronback wrote:
> I guess this never came up at the PMC level, but are we expecting each
> Modeling project to use the galileo flag for planning?
> http://wiki.eclipse.org/Development_Resources/Project_Plan/Modeling_Project
>
> Also, should we attempt a rollup of plans for Modeling overall? The
> Planning Council will need to provide some form of rollup for the community,
> but we're not sure what that will look like yet. It's a future topic, so I
> figured I'd solicit feedback from Modeling... Thoughts?
>
> Thanks,
> Rich
>
>
> _______________________________________________
> modeling-pmc mailing list
> modeling-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/modeling-pmc
>
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
