Community
Participate
Working Groups
According to the rules [1] and in order to remove the 'nonconforming' red slashes [2], please add " (Incubation)" to your feature.xml and MANIFEST.MF files, according to the examples in the wiki [3]. [1]http://www.eclipse.org/projects/dev_process/incubation-conforming.php [2]http://www.eclipse.org/projects/ [3]http://wiki.eclipse.org/Modeling_Project_Releng/Building_Zips_And_Jars#Incubation_Status You will need to do this for all active branches. When done, please add emo@eclipse.org to the cc: of this bug so that they can remove the nonconforming status icon. -- Eike: if you have time to do this, please do; otherwise I will roll it into the work I'll be doing shortly to migrate you from the EMFT build to the Modeling build. It's been a long time since your last published build -- are you still committing code in CVS? When would be a good time for me to copy your CVS from /cvsroot/technology to /cvsroot/modeling?
Per discussion in bug 197174, adding Sharon, Janet, Bjorn and the webmasters so everyone's aware of what needs to be done here. Same story, same approvals, same CVS changes... different components.
(In reply to comment #0) > Eike: if you have time to do this, please do; otherwise I will roll it into the > work I'll be doing shortly to migrate you from the EMFT build to the Modeling > build. It's been a long time since your last published build -- are you still > committing code in CVS? When would be a good time for me to copy your CVS from > /cvsroot/technology to /cvsroot/modeling? Nick: Yes, I'm committing lots of code to HEAD all the time ;-) What do mean with "active branches"? I have a R_7_0_maintenance ranch or so which I still need for the migration work to 0.8 (HEAD). There's no work done on the old branch and I don't expect maintenance releases on it. After we got HEAD to publish properly I don't need the old branch anymore. Do you think I have to change something in the old branch only to support this request? For HEAD is it enough when I add " (Incubation)" to the plugin and feature names?
(In reply to comment #0) > When would be a good time for me to copy your CVS from > /cvsroot/technology to /cvsroot/modeling? How long will the process of copying last? Is it really a copy? I mean, can I use both locations for a certain period? I ask because in this case it could be better not to copy everything but rather only HEAD. I could use the old location to access the maintenance branch until I feel that I'm ok with only HEAD in the new location. Then you could archive/delete everything from the old location.
(In reply to comment #2) > What do mean with "active branches"? I have a R_7_0_maintenance ranch or so > which I still need for the migration work to 0.8 (HEAD). There's no work done > on the old branch and I don't expect maintenance releases on it. After we got > HEAD to publish properly I don't need the old branch anymore. Do you think I > have to change something in the old branch only to support this request? Any branch on which you plan to release more builds is "active" in this context. If the branch is closed (like, for example, Eclipse 3.0.2's R3_0_maintenance branch, because there's no plan to do a 3.0.3 build), then you need not do anything to it for compliance, at least that's my hope. (I'll verify this with Bjorn once we're happy in HEAD again.) > For HEAD is it enough when I add " (Incubation)" to the plugin and feature > names? Yes -- there's two places to add " (Incubation)" in the feature.xml files and one place in the MANIFEST.MF files. See wiki for links to examples, or see bug 197820 for the history. (In reply to comment #3) > How long will the process of copying last? Is it really a copy? I mean, can I > use both locations for a certain period? It's a physical `cp` command (not a cvs copy) so it takes a few minutes and copies all the ,v files including full commit history. Yes, you can commit code to both locations after the copy, but there's little benefit except that you could do an "emft" (releng 1.0) build from the old location while I set up the new location for a "modeling.emft" (releng 2.0) build. All you'd end up with is a situation where you have to make the same code changes in two places. > I ask because in this case it could be better not to copy everything but rather > only HEAD. I could use the old location to access the maintenance branch until > I feel that I'm ok with only HEAD in the new location. Then you could > archive/delete everything from the old location. Given you're not doing builds right now, it should be safe for me to copy the sources over, modify your .releng stuff, and start doing fresh builds from the new location. Here's the mapping: Old code: /cvsroot/technology/org.eclipse.emft/cdo /cvsroot/technology/org.eclipse.emft/releng/cdo /cvsroot/technology/org.eclipse.emft/net4j /cvsroot/technology/org.eclipse.emft/releng/net4j Will be moved to: /cvsroot/modeling/org.eclipse.emf/org.eclipse.emf.cdo /cvsroot/modeling/org.eclipse.emf/org.eclipse.emf.cdo.releng /cvsroot/modeling/org.eclipse.emf/org.eclipse.emf.net4j /cvsroot/modeling/org.eclipse.emf/org.eclipse.emf.net4j.releng Note it's "emf" not "emft" (for a number of reasons), and the structure UNDER the above folders is mostly unchanged (plugins/, tests/, examples/, doc/). The one restructuring change comes as a result of improvements/simplifications in the new build system. I'll have to move your SDK feature so it's no longer nested INSIDE your runtime feature: plugins/org.eclipse.*-feature/org.eclipse.*.sdk --> plugins/org.eclipse.*.sdk-feature So... long story short. All that's required from your end is that you: a) check in anything you have local to your machine NOT already in CVS (from all branches you're working on) b) give me a window in which I can do the copy (eg., "you can do the copy any time today between 1pm and 5pm, GMT-4") c) check out everything from the new location d) continue development using the new cvs repo path Note also that under the new build system, the build will not tag cvs for you; instead, you either build from HEAD directly (and optionally tag thereafter) or you tag your sources, update your map file, and then run a build. This change is for security reasons so that the only person changing your files is you, not a shared build machine/userid. Also means you can mix and match tags within the map file so that certain parts of your code can be in development but NOT be provided to a build. Extra steps, but also more control.
Nick, I'm finished with my changes and have committed everything. Can you copy my CVS folders now? BTW. should I change the following values in my feature.xmls? <url> <update label="%updateSiteName" url="http://download.eclipse.org/technology/emft/updates/"/> </url>
(In reply to comment #5) > Nick, I'm finished with my changes and have committed everything. > Can you copy my CVS folders now? > > BTW. should I change the following values in my feature.xmls? > > <url> > <update label="%updateSiteName" > url="http://download.eclipse.org/technology/emft/updates/"/> > </url> > Copy completed. Yes, new update site will be http://download.eclipse.org/modeling/emft/updates/.
I don't have write access to the new repository ;-(
(In reply to comment #7) > I don't have write access to the new repository ;-( That's my bad ... should be group-writable now.
Hmm, I've accidentally checked out the new locations anonymously. Made many changes. When committing I got the write access denied message. Noticed my fault and changed the userid to estepper locally. Now I get "no such user estepper in CVSROOT/passwd" I even can't checkout with my own userid. Switching back to old locations is bad in this situation. I hope that my access to Modeling is granted soon.
It works now! Thank you ;-)
Nick, who will review this bug (fix) so that we can mark it ASSIGNED?
Well, once we have a working build (bug 202417 and bug 202418) we can verify the contents conform to incubation rules and close this bug. I plan to handle the incubation stuff and releng migration concurrently, so these three bugswill all get closed together, once it's done.
That's great! I think that I've already done all the incubation stuff.
Created attachment 78796 [details] mylyn/context/zip playing with mylyn task context attachment
(In reply to comment #13) > That's great! > I think that I've already done all the incubation stuff. Net4j incubation stuff done. CDO incubation stuff pending on bug 202418, but I think all the "-incubation" stuff is in place in both your sources and the .releng module. Can you verify that what you see on the update site is what you expect / want to see? To run an update site test-build, do this: a) ssh to emft.eclipse.org b) cd /home/www-data/build/modeling/scripts/; ./buildUpdate.sh -sub net4j -Q -buildID <somebuildID> c) open up Eclipse, and point the Update manager at http://emft.eclipse.org/modeling/emft/updates/site-interim.xml, where your unpublished N or I build will be. If you're satisfied -- for both Net4j and CDO -- you can close this bug. Note that a real promote will just overwrite the temp content with real xml + jars, so there's no clean up required.
Created attachment 78925 [details] Console Log with UM Errors Nick, buildUpdate.sh is not working. See attachment
Somehow ${buildDesc} is empty. And in promote.net4j.properties I've seen: #default branch branch=0.7.0 cvsbranch=R0_7_maintenance which should be: #default branch branch=0.8.0 cvsbranch=HEAD
(In reply to comment #17) > Somehow ${buildDesc} is empty. > > And in promote.net4j.properties I've seen: > #default branch > branch=0.7.0 > cvsbranch=R0_7_maintenance > > which should be: > #default branch > branch=0.8.0 > cvsbranch=HEAD properties files updated for net4j and cdo; note that you could also have just passed in -branch 0.8.0 and -cvsbranch HEAD to work around these incorrectly set default values. ;-)
(In reply to comment #15) > If you're satisfied -- for both Net4j and CDO -- you can close this bug. Was this meant for me or for the reporter/reviewer of this bug? From my point of view it can be closed...
(In reply to comment #19) > Was this meant for me or for the reporter/reviewer of this bug? > From my point of view it can be closed... Since I'm the reporter, I'll just go and close this, then. ;-)
Move to verified as per bug 206558.
Reversioned due to graduation
CLOSING
