[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [wtp-incubator-dev] More on XSL Graduation ...
|
> While I agree, I also view the WTP Incubator as it's own project,
> and the XSL Tools as a sub project within that project.
Have to be carefully transposing personal views onto technical terms with
specific definitions in the process. :)
Right now XSL Tools is a component, not a project. That has particular
implications from process standpoint. Until recently, it was not possible to
have arbitrary nesting of projects, so components were frequently created
when a project would have been more appropriate. Since the process change,
I've seen more and more projects converting components into projects.
> In some ways, this is why I would eventually like to see a true
> XML Development Tools project either in WTP or housed in the Technology
project.
I would agree with that. The large potential scope of XML development tools
functional area, the pace of growth of activity in this area and the
importance of positioning Eclipse as a viable player in this area all argue
for a dedicated project. So, why don't you propose the XML Tools project
(with XSL Tools as the initial component) right now? It doesn't make much
sense to move this code first into source editing while planning on moving
it again later. In fact, if you were feeling really aggressive, you could
even use the new project to stake out org.eclipse.xml namespace.
If you do end up proposing a separate project, I would recommend starting it
out as WTP sub-project while you have dependencies on parts of WTP. One of
the things that would hopefully happen once there is a dedicated XML tools
component is that some of the existing pieces from other WTP projects (XML
editor, XSD support, etc.) would eventually find their way into it. If that
happens and interest in this area keeps growing like it has been so far, I
can see this project moving to the Tools project or even becoming a
top-level project in an extreme case. Technology project would not be the
right place as it's an incubator for emerging projects rather than a place
where mature projects can remain indefinitely.
- Konstantin
-----Original Message-----
From: wtp-incubator-dev-bounces@xxxxxxxxxxx
[mailto:wtp-incubator-dev-bounces@xxxxxxxxxxx] On Behalf Of David Carver
Sent: Wednesday, February 18, 2009 4:53 PM
To: WTP Incubator Dev list
Subject: Re: [wtp-incubator-dev] More on XSL Graduation ...
While I agree, I also view the WTP Incubator as it's own project, and the
XSL Tools as a sub project within that project. I see the XML Security
project as a sub project, JAXWS, VEX, and XQuery all fall into these
catagories as well. It's a place to house projects that are incubating, that
may eventually graduate to another WTP project.
In some ways, this is why I would eventually like to see a true XML
Development Tools project either in WTP or housed in the Technology project.
As right now, for some of these, Source Editing isn't necessarily the place
for them. The reason is that they cover much more than source editing. XSL
Tools in particular covers XSLT Editing, but also Launching and Debugging as
well.
So I see the need for these holding areas for the incubating project.
With regards to VEX and XQuery. Both will get more attention once XSL Tools
graduates. At least from my end all of my energy is focused on XSL Tools,
and will be able to split some of that attention a bit once we graduate.
With out the incubator, you are correct, it really is overly complicated to
get a project going. So much so that it discourages people that aren't
strategic members from bringing projects that could be housed at eclipse
over.
Dave
Konstantin Komissarchik wrote:
> > I don't know what Mike and Bjorn said, of course, but not sure WTP
> Incubator is what they intended.
> Well, the comments were directed at the EMF incubator as they were the
> first to my knowledge to setup one of these persistent incubators, but
> since Platform Incubator and WTP Incubator have both copied that
> pattern, the comments apply here as well. The issue is that life-cycle
> state transitions (like releases and graduation) can only be done at
> the project level (rather than the component level). In addition to
> that, projects aren't supposed to remain in incubation indefinitely.
> They are supposed to get to the graduated state or shutdown phase.
> Clearly persistent incubators will never leave the incubation stage.
> From process standpoing, it doesn't really matter that parts of the
> project are actively moving through all the stages since technically
> they can't move independently.
> The concept of a persistent incubator came about as a back-door (not
> technically approved by the development process, but EMO is not
> exactly shutting these down either) solution for the problem of how
> difficult it actually is to start a project at Eclipse. Between the
> process and the infrasture needs, the function of the persistent
> incubators is to ammortize the costs as to lower the overhead bar and
> attract people who would not normally be interested. If there was an
> effective and low overhead push-button solution for starting projects
> then there would not be a need for persistent incubators. Every new
> incubation feature would get its own project which would release,
> graduate or die by itself (under supervision of a top-level project PMC).
> That's the background. It sounds like you have figured out a way to
> handle this "graduation" with EMO, which is ultimately what matters.
> Results over process.
> - Konstantin
>
> ----------------------------------------------------------------------
> --
> *From:* wtp-incubator-dev-bounces@xxxxxxxxxxx
> [mailto:wtp-incubator-dev-bounces@xxxxxxxxxxx] *On Behalf Of *David M
> Williams
> *Sent:* Wednesday, February 18, 2009 3:34 PM
> *To:* WTP Incubator Dev list
> *Subject:* RE: [wtp-incubator-dev] More on XSL Graduation ...
>
> Thanks for the suggestion, and I suspect this would technically handle
> the IP requirements.
> But, ideally, a graduation review is a bit more. For example, they
> should document that they have adopters, end-users, are responsive to
> bugs, mailing lists, meet milestones, etc.
>
> I don't know what Mike and Bjorn said, of course, but not sure WTP
> Incubator is what they intended.
> Especially, if you contrast that with another incubating project in
> WTP, that has been incubating too long and for which the PMC and
> Project Lead are actively discussing next steps.
>
> And ... we have "killed" components in WTP Incubator that were not
> making progress ... and any WTP Incubator leader/committer should
> bring issues to my attention (as WTP Incubator lead) so they can be
> attended to.
>
> Thanks again.
>
>
>
> Inactive hide details for "Konstantin Komissarchik" ---02/18/2009
> 05:08:02 PM---So out of my own curiosity, how can part of a
> p"Konstantin Komissarchik" ---02/18/2009 05:08:02 PM---So out of my
> own curiosity, how can part of a project graduate or put another way,
> why is the gradua
>
>
> From:
> "Konstantin Komissarchik" <konstantin.komissarchik@xxxxxxxxxx>
>
> To:
> "'WTP Incubator Dev list'" <wtp-incubator-dev@xxxxxxxxxxx>
>
> Date:
> 02/18/2009 05:08 PM
>
> Subject:
> RE: [wtp-incubator-dev] More on XSL Graduation ...
>
> Sent by:
> wtp-incubator-dev-bounces@xxxxxxxxxxx
>
> ----------------------------------------------------------------------
> --
>
>
>
> So out of my own curiosity, how can part of a project graduate or put
> another way, why is the graduation review even necessary in this case?
> Would it be more straightforward to take the plugins and features in
> questions, make a giant patch out of them and create a contribution
> bug on the source editing project (together with the corresponding
> CQ). Once the CQ is approved and the patch committed, the current XSL
> tools committers can be voted in using the regular process. Maybe
> that's just subverting the process, but what I hear from Bjorn and
> Mike, persistent incubators are themselves considered as subverting
> the process.
>
> In any case. Thought I'd throw this out in case this would make
> paperwork easier.
>
> - Konstantin
>
> ----------------------------------------------------------------------
> --
> *From:* wtp-incubator-dev-bounces@xxxxxxxxxxx
> [mailto:wtp-incubator-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Nitin
> Dahyabhai*
> Sent:* Wednesday, February 18, 2009 1:51 PM*
> To:* WTP Incubator Dev list*
> Subject:* Re: [wtp-incubator-dev] More on XSL Graduation ...
>
>
> So how's this work with committer rights? Do the XSL committers
> "graduate" into being Source Editing committers? Or do we have to
> nominate and vote for each individually?
>
> Regards,
> ---
> Nitin Dahyabhai
> Eclipse WTP Source Editing
> IBM Rational
>
> *David M Williams/Raleigh/IBM@IBMUS*
> Sent by: wtp-incubator-dev-bounces@xxxxxxxxxxx
>
> 02/18/2009 01:49 AM
>
>
> Please respond to
> WTP Incubator Dev list <wtp-incubator-dev@xxxxxxxxxxx>
>
>
> To
> WTP Incubator Dev list <wtp-incubator-dev@xxxxxxxxxxx> cc
>
> Subject
> [wtp-incubator-dev] More on XSL Graduation ...
>
>
>
>
>
>
>
>
> Just to bring everyone up the the same level of knowledge as myself
> (little as that is :) ...
>
> I have learned that the first step in "graduating" the XSL components
> into the Source Editing project is to make sure the IP Log is in
> order, and everything "all clear" from an IP point of view, and it's
> "approved" by the Eclipse Foundation's IP Staff. And, only after that
> is done, is the actual graduation scheduled and other materials provided.
>
> Normally, this is semi-automatic, using the automatic IP Log, but in
> our case, that log includes everything in WTP Incubator, not just XSL.
> So ... we'll have to do a "manual" one.
>
> I think this won't be too hard, since we can, to some degree, use the
> automatic IP Log and just take out stuff that doesn't apply to XSL. I
> think we should do this as a document on our website (not wiki) and in
> Open Document Format, since at some point we need to "freeze it" (e.g.
> in PDF format) to provide to the Eclipse Foundation for long term
> records. I'll be able to start work on this next week (if no one else
> volunteers), but if anyone wants to take a look at our starting point,
> here's the URL to the automatic IP Log: _
>
> __http://www.eclipse.org/projects/ip_log.php?projectid=webtools.incuba
> tor_
>
> Thanks,
> _______________________________________________
> wtp-incubator-dev mailing list
> wtp-incubator-dev@eclipse.org_
> __https://dev.eclipse.org/mailman/listinfo/wtp-incubator-dev__________
> ______________________________________
> wtp-incubator-dev mailing list
> wtp-incubator-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-incubator-dev
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.0.237 / Virus Database: 270.10.25/1957 - Release Date:
> 02/17/09 07:07:00
>
> ----------------------------------------------------------------------
> --
>
> _______________________________________________
> wtp-incubator-dev mailing list
> wtp-incubator-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-incubator-dev
>
_______________________________________________
wtp-incubator-dev mailing list
wtp-incubator-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-incubator-dev
