[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [modeling-pmc] Infrastructure Changes
|
Sorry for the confusion. I was trying to present the two possible paths and
their impacts.
Since everyone's apparently in agreement with working in the current cvs,
let me recap the plan:
1. copy dev.eclipse.org:/cvsroot/technology and tools to
emft.eclipse.org:/cvsroot/modeling [DONE]
2. reorg cvs content on emft; fix builder to work with new organization
[TBD]
3. merge emf, uml2, emft builders into one builder [this is about 75% done
already, as I've been working towards this for some time]
4. prove builds work; run a few and let developers sniff test them to be
sure
5. commit new releng content from emft.eclipse.org to dev.eclipse.org
THEN
6. ask webmaster to copy emf, uml2, emft projects in tools and tech to
modeling
7. run builds; sniff test, etc.
8. ask webmaster to remove emf, uml2, emft projects from tools and tech.
9. refactor plugins (if necessary) & update releng to support changes (both
in dev.eclipse.org)
Once that's done, it'll be time for the next project(s) to jump on board.
Could be MDDi, GEF, GMF... whoever's ready. Note that there's nothing in
the emf+ build which will do what CruiseControl currently does for GMF.
Well, maybe that's too strong a statement. We'll talk more later. ;-)
Cheers,
--
Nick Boldt :: Software Developer, IBM Toronto Lab
Eclipse Modeling Framework :: http://eclipse.org/emf
905/413/4308 (t/l 969) :: codeslave@xxxxxxxxxx
Richard Gronback
<richard.gronback
@borland.com> To
PMC members mailing list
26/07/2006 09:29 <modeling-pmc@xxxxxxxxxxx>, Nick
AM Boldt/Toronto/IBM@IBMCA
cc
Max Feldman
<Max.Feldman@xxxxxxxxxxx>
Subject
Re: [modeling-pmc] Infrastructure
Changes
This is how I interpreted Nick?s first email; that is, the purpose of
setting up emft.eclipse.org with a CVS structure was in order to get us
moving toward a consolidated build. The focus was on releng, and not on
having development work out of this repo. It?s up to each project to
manage its move when they are ready, with the MDT pieces requiring the
formation of a new project beforehand (at least in parallel). Or, did I
miss something?
Best,
Rich
On 7/26/06 9:18 AM, "Kenneth Hussey" <khussey@xxxxxxxxxx> wrote:
Nick,
If the purpose of this exercise is to get the build infrastructure to
work against the new structure, I'd suggest taking a snapshot of
what's in CVS (as you've done), restructuring it based on what we
think the new layout will be, and updating the build scripts, etc. to
work against it. We should continue to develop and build against the
current CVS structure on dev.eclipse.org, and when the time comes,
simply migrate the releng plug-ins from your sandbox and reorganize
the project folders on dev.eclipse.org...
Cheers,
Kenn Hussey
Eclipse UML2 Project Lead
Rational Software, IBM Software Group
770 Palladium Drive
Kanata, Ontario, K2V 1C8
T: (613) 599-3980 F: (613) 599-3912
Nick Boldt/Toronto/IBM 07/25/2006 04:05 PM
To
Kenneth Hussey/Ottawa/IBM@IBMCA
cc
Max Feldman <Max.Feldman@xxxxxxxxxxx>, PMC members mailing list
<modeling-pmc@xxxxxxxxxxx>
Subject
Re: [modeling-pmc] Infrastructure Changes
Well, as I see it, we have two options...
a) start using the new cvs
b) keep using the old cvs
if (a) - there'd be no need to synch back, but you'd also not get
your changes built until after the releng changes were working
if (b) - we'd have to merge the changes over into the new cvs once
the releng was ready, but you'd be able to publish builds as we go
using the old builder on emf.torolab, and the current cvs on
dev.eclipse
I suppose it depends on:
* how urgent the changes are - that is, how urgent they need to be
published in new builds,
* if you want them to be part of MDT or part of the current projects
then later MDT as well, and
* your comfort level with assisting me in the synch back step if we
choose (b).
The other thing to consider is that I'm only looking at moving files
around and working on the releng piece. I'm not planning to refactor
anything (should I be?) to a new namespace like
org.eclipse.mdt.whatnot, so I shouldn't be changing anything in the
actual plugin code, just the folders in which it resides and the
releng stuff to support those moves.
Once UML2, XSD, OCL and EODM are repositioned in
/cvsroot/modeling/mdt/releng and /cvsroot/modeling/commons/releng (or
something like that), and we have working builds again, THEN we can
perform the code synch/merge (either a straight copy, an rsync, or
some manual, labour-intesive diff thing (?)), test out the builds
still work, and launch into any refactoring still to be done.
Does that sound like a reasonable approach? Which scenario, (a) or
(b) - or another as yet unknown idea, (c) - sounds like the best
solution for you?
Cheers,
--
Richard C. Gronback
Borland Software Corporation
richard.gronback@xxxxxxxxxxx
+1 860 227 9215
