Bugzilla – Full Text Bug Listing
| Summary: | [releng] Adapt buckminster files to produce Juno builds | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] OCL | Reporter: | Adolfo Sanchez-Barbudo Herrera <adolfosbh> | ||||
| Component: | Core | Assignee: | OCL Inbox <mdt-ocl-inbox> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | ed | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Adolfo Sanchez-Barbudo Herrera
bug/350862 pushed to remote repository bug/350862 merged into master and then pushed to remote repository. I've also : - Removed the archived plugins from the examples features. - Versions[1] increased in ocl.examples and ocl.master feature. Now I'm wondering: - Should bug branches be created if we deal with trivial changes ? -> I think that, as long as possible, a commit should always start with the releted bug (take a look to my commits messages). - Should a major version of a feature be increased, when an included plugin is removed from it ? BTW, our Juno build is running, and it looks it's lasting more time than it lasted days/weeks ago... :) [1] http://wiki.eclipse.org/Version_Numbering#Versioning_features Best Regards, Adolfo. The Indigo maintenance releases should include all the plugins released in Indigo; perhaps we were too quick in archiving them. If it's too awkward to build them from 'archive' perhaps they should be moved back again. (In reply to comment #1) > Now I'm wondering: > - Should bug branches be created if we deal with trivial changes ? -> I think > that, as long as possible, a commit should always start with the releted bug > (take a look to my commits messages). This seems to be a good idea; otherwise you're working direct on master, but for releng activities which are rather interactive anyway, I think a bug branch and detailed Bugzilla patch is just making things unnecessarily hard. Unless of course you can easily redirect Hudson, in which case master would be the last successful build and your experiments would all be on a branch. Until you have success, no need for the branch. > - Should a major version of a feature be increased, when an included plugin is > removed from it ? For non-examples perhaps, but even here I think some discretion is sensible for a reorganisation. Concerning the maintenance stream, I commented in Bug 349114 that I'll make buckminster rmap file find the archived stuff in the "arhive" folder. Concerning the main development stream, I think I found the last needed change: examples.tests plugin depended on the archived org.eclipse.ocl.examples.parser one. I forgot to increase the tests plugin version, though... Doing a new commit Hopefully, this current running build will be finally blue >.< Regards, Adolfo. (In reply to comment #3) > > Hopefully, this current running build will be finally blue >.< > I give up, Running again to track the test plugin version increase, but the build should have worked without the last error :\ In local, I don't have any error by buckminster, concerning ocl plugin dependencies... I go home Best Regards, Adolfo. Created attachment 199326 [details]
Fixing OCLstdlibRenameStrategy
Some git patch creation practicing.
A fix of the OCLstdlibRenameStrategy to make our master build work.
Ed, feel free to change this in the future. You will probably find conflicts if you have changed this in any bug branch. A good chance to practicing conflicts resolutions with git (via EGit and/or command line).
+1 Looks plausible to me. I think Xtext declared a load of interfaces internal at RC1. This is one of them so Xtext is guiltless. This code doesn't really work anyway, the Xtext functionality was evolving too close to the bell to get it properly customized. Probably want to revisit these customizations at M5/M6 when Xtext may have stabilized. You may comment it all out if it helps. Well, It looks like things start to work... Servers look like to hang, but we start to have blue builds :) I still need to sort out some bits. Mainly: - EMF Library Examples are not zipped, by the moment. I'll fix the buildZips.xml to recover this. - Textile Doc is not build is not executed, by the moment. Ed, I leave this task for you. On the other hand: - I'm investigating why some plugins in the generated P2 repository have the .qualifier 4th segment See [1] and [2] - I need to test that publishing every kind of build nicely works. As conclusions of my last releng issues during GIT migration (interesting for other relengs): - Dealing with a buggy buckminster-git provider (Git Reader Types), which relies on a buggy EGit component, has been a high-risk task. So I've finally configured the buckminster rmaps to use "Local reader types" to fetch our sources from hudson workspace instead of using "Git reader types". These sources are fetched and updated into hudson's workspace from our git repository by the means of hudson (git-plugin, which was anyway needed to invoke the releng buckminster scripts). This approach also avoids waiting for other stopper issues I've found with our maintenance branch (also related to buckminster-git provider and my stupidities or ignorance, see Bug 350130 and Bug 324441). - I was having some problems concerning the signing process. Typical case in which whatever may be occurring (severs problems, buckminster problems, my stupidites,...). Once I have had some time to look into the problem, I've realized on my stupidities, in this case. See Bug 35142. [1] https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.2-master/374/artifact/MDT-OCL.p2.repository/plugins/ [2] https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.2-master/375/artifact/MDT-OCL.p2.repository/plugins/ Best Regards, Adolfo. Doing some updates, I've already fixed the EMF library examples zipping. The servers are not helping due to instability, but I've been working on Bug349179, Bug 349300 and Bug 339464. I'll provide more detailed information in said bugs. Regards, Adolfo. We have (fortunately :) ) been producing Juno builds since time ago. Resolving this bug as fixed. CLOSED after a year in the RESOLVED state. |