Great, we’re getting closer… J
a) Well, nothing says we have to wait to build against the platform,
emf, and gef before the +2 week timeframe, just that we need to release our
milestone by that time. I expect we’ll be building against them as soon
as they are available, which gives us the same amount of time as anyone to
report defects, right? If we can release our milestone build the day after
EMF/GEF, I’m for that. ;)
b) Doh! I must be thinking about the holidays already, which made me
ignore the possibility of a Dec. 16 + 2 week milestone ;-) Excellent, we’ll
move them all up a milestone, which should take care of the other issues you
raised.
c) Agreed.
d) Agreed.
e) Right, if they all shift up a milestone, we should be good.
f)
I still
need to touch base with our localization team, but happy to have help
localizing for sure.
So, this leaves us with a Dec 30th
milestone to cover Functional, Bootstrap in February, Hatch in April, and spend
the platform’s RC0 timeframe bug fixing, polishing, etc.
If this sounds OK, I’ll clean this
up and put into a document we can post on the GMF website.
Thanks again,
Rich
From:
gmf-dev-bounces@xxxxxxxxxxx [mailto:gmf-dev-bounces@xxxxxxxxxxx] On Behalf Of Frederic Plante
Sent: Wednesday, October 05, 2005
12:23 PM
To: GMF
Project developer discussions.
Subject: RE: [gmf-dev] GMF Plan
Thanks Rich,
More
comments:
a)
The comment about defect fixes is more about Eclipse platform defects. If we
are +2, it means it will take at minimum 2w for us to use a fix we raise
against platform. Having one less week would be much more useful.I guess we
could be +2 but execute as a +1.1 by adopting EMF/GEF as soon as they adopt a
new platform. How about that?
b)
Hey buddy, you skipped Eclipse's M4 :-) Look at
http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_2.html,
Platform's M4 is Dec. 16th. This would align very well to our original GMF M1.
c)
All we need is to "insert" the Eclipse's M4 milestone, the other
milestones are probably close enough until we get the official platform plan.
d)
Then it seems we could easily formalize the April Milestone as our FF
e)
Graphical editors will very likely uncover many workflow issues/defects given
it is a major feature. Introducing them in the last feature milestone is risky.
Shouldn't we commit to something "Milestonable" earlier like in your
proposed mid-Feb milestone?
f)
As long as in our v1.0 GM we support everything a tool project needs to
support, such as languages and platforms, then this is fine. BTW: Any update
from Borland about IBM's offer to perform all translation for GMF's
documentation?
About
verbosity and clarity balance, that's not the issue, I am just being a
difficult teammate :-)
Thanks
- Fred
_________________________________
Frédéric Plante
Rational Software, IBM Software Group
770 Palladium Drive, Ottawa,
ON, Canada
tel: (613) 591-7034
"Richard Gronback"
<Richard.Gronback@xxxxxxxxxxx>
Sent
by: gmf-dev-bounces@xxxxxxxxxxx
10/05/2005 10:56 AM
Please
respond to
"GMF Project developer discussions."
|
|
To
|
"GMF Project
developer discussions." <gmf-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
RE: [gmf-dev] GMF Plan
|
|
Hi Fred,
Thanks for the feedback. I have some additional
information below.
a) I think you’re (or I am) misunderstanding what +1 vs. +2
means. In the Planning Council discussions, it meant that as there are
natural dependencies on other projects, there is a necessary staggering of
delivery of milestones to allow for a project to accept the dependent
milestones. So, in our case, as we’re dependent upon EMF and GEF
(primarily), we will need to allow them to take their week after the platform
in order to produce their milestone, which gives us a week after receiving EMF
+ GEF milestones to produce our milestone. It has nothing to do with getting
defect fixes faster, really.
b) As stated below, there will be functional capabilities of GMF
builds present by the end of Q405. But, there is no milestone to align
with at this point, so we went with the next one available.
c) Actually, the milestones below do
align with the platform milestones, but with a 2 week stagger, as described in
a). Technically, the platform milestones are not yet published, but the
dates I used are in line with what was discussed at the Planning Council
meeting. I expect to update them when they are firm, or we can remove
dates all together and just think +2 weeks after platform (or ASAP after EMF +
GEF, as I think of it).
d) The Platform’s end game was extended explicitly for the
purpose of getting themselves stable and to allow for the train projects to
align for a synchronized release. I don’t feel GMF will need this
amount of end game in order to have its 1.0 release ready. Also, as
stated, our final milestone will be more of a cleanup and preparation of APIs
and exit of incubation. I don’t foresee major functionality coming
in the last milestone period.
e) To me, having it “ready” will occur well before the
milestone date. The milestone releases are intended to be mini-releases
in themselves, so I expect the level of quality at each to be production
quality. I expect we will have suitable graphical capabilities in time
for EclipseCon 2006.
f) I do not recall the goal of becoming a Tools project for Eclipse
3.2. I believe we should aspire to exit incubation in parallel with
developing our 1.0 release. Technically, according to the guidelines, we
need to exit incubation before we can release a 1.0 version. We can worry
about transitioning to another PMC afterwards.
I hope this helps to clarify some of what’s
below… I guess I need to find a better balance between verbosity and
clarity J.
Best Regards,
Rich
From:
gmf-dev-bounces@xxxxxxxxxxx [mailto:gmf-dev-bounces@xxxxxxxxxxx] On Behalf Of Frederic Plante
Sent: Wednesday, October 05, 2005 10:29 AM
To: GMF Project developer discussions.
Subject: Re: [gmf-dev] GMF Plan
Hi Richard,
We have quite a few concerns with this plan:
a) Seems GMF should be a +1 project to allow us to get EMF/GEF/Platform
defects fixes faster.
b) Our original goal for M1 was 4Q05, now it seems it moved 2 months
later.
c) Post-GMF M1, we were supposed to follow Eclipse's milestones which are
6 weeks apart each, the proposed schedule does not align with Eclipse's milestones.
d) Eclipse will go feature freeze around April and then get into shutdown
mode until June. We should align to this as well if we want a productizable
tool
e) If we only plan to have graphical support "ready" in April,
not only will we miss EclipseCon, but we will not have time to make that major
feature product quality by GM
f) Our original goal was to become a Tool project for Eclipse 3.2.
What is proposed here is to become a tool after 3.2.
In summary, it is proposed that we:
1) Become a +1 project
2) Follow Eclipse's Milestones (including names as you suggested)
3) Target Eclipse M4 for what we called our GMF M1 back in Prague
4) Target Eclipse M5 for our graphical surfaces. This should allow us to
have something for EclipseCon
5) Target Eclipse M5 to become a Tool project (the result of M5 should be
good enough to request the move to a Tool project immediately after M5)
6) Align GMF's feature freeze with Platform's FF
It is very conceivable that we will fail to produce the product quality tooling
expected from the community for Eclipse 3.2 should GMF not commit to the above
recommendations.
Thanks
- Fred
_________________________________
Frédéric Plante
Rational Software, IBM Software Group
770 Palladium Drive, Ottawa,
ON, Canada
tel: (613) 591-7034
"Richard Gronback"
<Richard.Gronback@xxxxxxxxxxx>
Sent by: gmf-dev-bounces@xxxxxxxxxxx
10/05/2005 09:15 AM
Please
respond to
"GMF Project developer discussions."
|
|
To
|
"GMF Project developer
discussions." <gmf-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
[gmf-dev] GMF Plan
|
|
Hi All,
As you know, GMF is part of the 3.2 release train which means beginning with
the November 4th M3 milestone, we will need to be providing our own milestone
builds. GMF is a +2 project, which means our milestones must be available
within 2 weeks of the platform. EMF and GEF are both +1 projects, giving
them 1 week after the platform (so, each dependency level gets a week).
Below is a proposed set of milestone dates and high level goals.
I’ve added 2 weeks (more or less) to each platform milestone date,
with the exception of the final one, which is the same as the platform. Let
me know what you think of these:
M3 - Nov 18, 2005:
Theme: Clean - By clean I mean that our code needs to be properly copyrighted,
cleansed of commercial names, follow the prescribed naming conventions, all
build artifacts need to install and function, no deprecated API usage, etc.
Basic functionality will be present, although the following milestone
will focus on this aspect.
M4 - Feb 24, 2006:
Theme: Functional - By functional, I mean it should work end-to-end, with
attention paid to those requirements we marked as M1 during the kickoff
meeting. It is expected that builds prior to this (by end of ’05 as
discussed at kickoff) will have this ability, but the M4 milestone will be more
complete in this respect.
M5 - Apr 14, 2006:
Theme: Bootstrapped - Our graphical surfaces for definition and mapping should
be bootstrapped by this time, representing one aspect of "exemplary
tools" by the project, not to mention the ‘consume our own
output’ aspect.
1.0 - June 30, 2006:
Theme: Ready to Hatch - Meaning that we should be ready for transitioning out
of incubation. See guidelines on what this involves. A big part of
this will be our APIs, meaning we should eliminate "provisional"
APIs, look at extension points and their documentation, etc.
I'm not sure we should or need to have a dummy set of milestones to represent
M1 and M2, but I think our milestone numbers should be in synch with the
platform's, which is why we start with M3. Thoughts?
I will configure the build to start using the Platform, EMF, and GEF milestone
builds shortly.
Thanks,
Richard C. Gronback
Borland Software Corporation
richard.gronback@xxxxxxxxxxx
+1 860 227 9215
_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev