Adding Mike and Wayne for their comments on this matter.
Needless to say I am quite disturbed by this. From day 1, there
was nothing WTP-specific about Faceted Project Framework. The codebase started
in WTP because it was a convenient place to incubate this technology, but it
was always assumed that it would later move to a place where it could be perceived
as generic by potential adopters and be more accessible. For WTP to now deny
this move is quite frankly selfish to an extreme.
I understand that fear of losing control underlies this decision,
but I never imagined that it would override other considerations.
Over the last several years, WTP has become a hostile
environment for innovation and there has been a lot of stagnation in the core
WTP projects. Faceted Project Framework has been very successful for WTP use
cases, but it needs to evolve further to meet the needs of other projects. It
cannot do that in WTP. No backwards compatibility layer will be seen as good
enough. The only thing that matters is not disturbing the status quo.
I’d like to continue working on this technology and to help
other projects discover its benefits, but I cannot do that in the current
structure. If this decision stands, this framework just hit a dead end. Some
might view that as benefit as objects tends to remain rather stable at a dead
end, but I believe this will ultimately hurt rather than benefit WTP and its
adopters.
- Konstantin
From: wtp-pmc-bounces@xxxxxxxxxxx
[mailto:wtp-pmc-bounces@xxxxxxxxxxx] On Behalf Of David M Williams
Sent: Tuesday, June 22, 2010 1:19 PM
To: WTP PMC communications (including coordination, announcements, and
Group discussions)
Subject: Re: [wtp-pmc] Moving faceted project framework codebase
Konstantin,
The PMC has discussed your
request, and we think a move of this code would not be a good idea. There were
reasons discussed "for" and "against" but no consensus
could be reached that it would be the right thing to do, so the status quo
should be maintained. Its hard to summarize all the discussions, but we have
tried to capture the highlights of our discussions in our PMC meeting minutes.
The Faceted Project framework
is a much used and much appreciated framework in WTP and we believe that WTP is
its correct home. We hope you continue to improve and maintain this important
framework and help WTP to continue to be successful.
Thank you,
|
From:
|
"Konstantin
Komissarchik" <konstantin.komissarchik@xxxxxxxxxx>
|
|
To:
|
<wtp-pmc@xxxxxxxxxxx>
|
|
Date:
|
05/26/2010
04:44 PM
|
|
Subject:
|
[wtp-pmc]
Moving faceted project framework codebase
|
|
Sent by:
|
wtp-pmc-bounces@xxxxxxxxxxx
|
Esteemed members
of WTP PMC,
I would like
to join one of the upcoming PMC calls to discuss moving the existing faceted
project framework code base from WTP Common to the Faceted Project Framework
(fproj) project under Technology. The fproj project already contains the v-next
code line for the framework. I originally thought that it would make sense to
leave the existing code line in WTP while v-next is being developed, but
experience over the past year has shown this structure to be less than optimal.
It is more difficult than necessary to propagate changes from the maintenance
line to v-next, the community is fragmented between two projects (forums and
mailing lists) and governance issues can present a challenge.
In terms of
logistics, I’d like to propose the following:
1. Wait until
Helios is complete.
2. Do a move
review.
3. Ask EMO to
copy relevant plugins and features from WTP CVS location to the new project.
This will preserve all the history.
4. Start
producing builds from this code line. Same plugin id’s, feature id’s, package
names, etc. will be used as in WTP.
5. WTP build
is altered to consume these binaries instead of building from local source.
6. Ask EMO to
delete the moved plugins and features from WTP CVS repository.
The result
will be a 1.x code line for maintenance and backwards compatibility work
sitting alongside 2.x (v-next) code line. WTP would consume 1.x builds for
foreseeable future. When version 2.0 is ready, the next 1.x release will be a
backwards compatibility shim that will let existing code written against 1.x
releases work with 2.0 framework. Tentative release schedule is as
follows:
1.4.1 –
aligned with Helios SR1 dates
1.4.x – other
service releases as necessary
2.0/1.5 –
part of Summer 2011 release
Thanks,
- Konstantin_______________________________________________
wtp-pmc mailing list
wtp-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-pmc
