Yes, I think thats a very good summary Jesper. We can work in parallel, though I would appreciate some of your help on JUnits.
My feeling is that for launching, we can be at M4 by Jan 1st, and M5 the week after that. Thats because I have 2 weeks off work!
----- Original Message ----
From: Jesper Steen Møller <jesper@xxxxxxxxxxxxx>
To: WTP Incubator Dev list <wtp-incubator-dev@xxxxxxxxxxx>
Sent: Saturday, 22 December, 2007 2:43:02 PM
Subject: Re: [wtp-incubator-dev] Extensibility of XSLT editor menus, popups,
DOUG SATCHWELL wrote:
>
> I'm happy
for you to take on this part of the work. It is important
to
> get a plan together, and to keep the rest of the world up to date via
> the wiki. The planning itself needs to be a consultation process. It
> needs to be realistic too - I'm sure we all have full-time jobs so we
> need to keep the size of the tasks manageable.
>
+1
>
> OK - lets work on a milestone plan that we can use. I do want this to
> result in the XSL code getting published to an update site early on -
> the earlier we get it there the sooner we can work on ironing out the
> bugs. I'll explain why I think we can do this.
>
> I think that there are 2 streams of development here as per the
> proposal at
>
http://www.eclipse.org/webtools/incubator/proposals/XSLTools_proposal.html.
>
>
> 1) XSL launching + debugging.
>
> 2) XSL editing capabilities and validation.
>
The intersection between is what goes into 'core': XSL Schema catalog
entries and the contentType extension.
Don't forget the XPath view and the customized XML outline view.
>
> Stream 1 is actually quite mature because it has been based on
> existing mature code that has been converted. My aim is to get this
up
> to scratch within the next 2 weeks - that means documentation, JUnit
> tests and integration with the WTP build process. This is the spit
and
> polish.
>
>
>
> Stream 2 is much less mature - we need a great deal more than spit
and
> polish here, so milestones for this are distant.
>
There's been a lot of restructuring in this, but it's coming along bit
by bit, I just haven't committed anything yet.
>
> The point is that the 2 streams are more or less independent. You can
> deliver one without the other, as long as the plugins are suitably
> arranged. And the sooner we deliver something - even if it is just
> stream 1 - then the better for us because we get to know how the
> process works and get people using and testing it for us. As
> Konstantin points out, it looks like we should be getting it built as
> a separate distro first.
>
> So what I would like to propose is that in the first part of the plan
> we make a determined effort to get stream 1 to production quality and
> released. Then we turn our attention to stream 2.
>
Or we could work in parallel - as these proposed streams are pretty
much independent.
>
> In other words, we can get stream 1 to RC1, while stream 2 is still
> at M1.
>
> Is that sensible?
>
Er, I'm a little wary of re-using milestone labels such as M1 and RC1
which will easily confused with the Ganymede plan items.
I'd suggest referring to the Ganymede milestone plan (+3 stage) as a
timebox and then focus the effort accordingly in a tabular fashion:
Feature: XLST Launching
M4: Main functionality done
M5: Tested and packaged (update site)
M6 [API freeze] End user help
M7: Cheat sheet, etc.
...
Feature: XPath view
M4: As imported from Orangevolt XLST + namespace support
M5: Enhancement xxx, yyy, zzz, Bug aaa
M6 [API Freeze] Tested and packaged (update site)
M7: End user
help
...
Feature: Validator
M4: Use existing X-Assist features in existing validation framework
M5: Move to new validation framework
...
The features could then be evaluated and tested independently.
Well, that's my take on this, but ultimately, I'm not religious in
these
matters.
-Jesper
_______________________________________________
wtp-incubator-dev mailing list
wtp-incubator-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/wtp-incubator-dev