Hmm… A closed discussion and we’ll get back to you? Strikes me a
little contrary to the spirit of open source…
From:
wtp-pmc-bounces@xxxxxxxxxxx [mailto:wtp-pmc-bounces@xxxxxxxxxxx] On Behalf
Of David M Williams
Sent: Friday, May 28, 2010 12:43 PM
To: WTP PMC communications (including coordination, announcements, and
Group discussions)
Subject: Re: [wtp-pmc] Moving faceted project framework codebase
I'll discuss
with the PMC soon, and we'll get back to you on an appropriate date. My guess
is it would be 6/15, at the earliest.
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