The ...build-feature would have a dependency on all projects that need to be built (since Buckminster is driven by metadata) and would also include information that's used to package and publish build results.
Cheers,
Kenn
On Tue, Jul 13, 2010 at 1:20 AM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
Hi Kenn
Your opinion is worth a lot, particularly when I can't really decide.
There doesn't seem to be a clear policy; itemis (TMF, MWE are moving to
separate top projects), Obeo (ATL, Acceleo) are moving to one, IBM
(GMF, EMFq) are staying with two.
I don't think a releng committer need be undeserving by having
selective access. I sometimes find not having write access to EMF a
useful protection. An overcommit is an easy accident, and releng
activities shouldn't affect code. We can always move the code if we do
need a separate releng.
A ...releng.buckminster plugin is obviously sensible and contains the
CVS to ZIP 'transformation'.
A ...releng.build may be the best home for the Xtext MWE scripts
(currently in src) that perform the .xtext to *.java transformation.
Unlike genmodel, these significantly increase the plugin dependencies
so need to be separate.
I'm not quite sure what you had in mind for the ....build-feature.
I'm not sure that moving old relengs helps since the CVS history is
lost and the new location is not used. The old project remains visible
in CVS forever so access by Tag is possible. For trivial residual
READMEs, I was impressed by MOVED_TO_org.eclipse.emf.mwe.releng.
I'm doing slow progresses regarding the transition to buckminster
(bucky) build system. Just reading documentation (BuckyBook) and making
some experiments with examples. In principle, having a look at other
modeling projects releng, it should be quite straightforward having our
builds in buckminster. At this point, I would need to do some commits
to our repository in order to go on with my next steps/experiments.
However, before that, I would like to get a consensus about the releng
stuff structure.
Taking into account that our MDT-OCL projects reside in
"/cvsroot/modeling/org.eclipse.mdt":
- Our current releng stuff reside in the "org.eclipse.ocl/releng"
folder which is a project named "org.eclipse.ocl-releng"
- We have an "org.eclipse.ocl.releng" project which is the old project
which managed the releng previous to moving the build system to Athena.
On the one hand, Ed has suggested to move the new bucky build system to
the "org.eclipse.ocl.releng" project so that an MDT-OCL release
engineer wouldn't need to be an "org.eclipse.ocl" project commiter.
He/she would need to be a "org.eclipse.ocl.releng" instead.
On the other hand, I've noted that all modeling projects I've checked
are using the same location to manage the releng stuff. For instance,
EMF is located in "org.eclipse.emf/releng" folder.
So, in order to be aligned with other modeling projects and avoid
confusions, I'm inclined to keep the releng stuff in the
"org.eclipse.ocl/releng" folder, with the following structure:
+ org.eclipse.org:
+ releng (no project)
+ org.eclipse.ocl.releng.buildsystem1 (a project)
+ org.eclipse.ocl.releng.buildsystem2 (a project)
...
+ org.eclipse.ocl.build-feature (a project)
README.txt
So that:
1. The README would explain the current (and previous) build system
used by the project.
2. I'd work org.eclipse.ocl.releng.buckminster project which would
allow us to do the MDT/OCL builds via bucminster.
3. All the current build stuff would stay as it is, until the bucky
builds are stable and properly working. After that, all the current
stuff could be moved to a "org.eclipse.ocl.releng.athena" project (as
EMF has).
4. Regarding the permissions of the "external" releng engineers. I
think that anybody (me or anyone else) who is doing releng stuff for
the project should be considered as a deserved committer, regardless
he/she is really contributing any kind of development for the project.
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.830 / Virus Database: 271.1.1/2998 - Release Date: 07/12/10 07:36:00
