[emf-dev] Re: EMF, EMFT, MDT, M2T : Projects, Components, and Committers

["Nick Boldt" <codeslave@xxxxxxxxxx>]

Bjorn:

My intent with the current structure of CVS and our committer/contributor database was to create a 1:1 mapping between components and cvs modules. Rather than needing yet another meta level for component name, I figured it would be simpler to just use the cvs module as the component name... hence the "
org.eclipse.emf." and "org.eclipse." prefixes. These are directory names as per the directory structure spec set forth by Kenn when MDT was born, and the pattern applied for consistency to M2T, EMF and now finally EMFT.

What I'd really like is if the unix groups, cvs modules, and components matched up the same in all cases:

http://www.eclipse.org/modeling/emft/project-info/team.php?export=project,component,groupname,path,committerid

Unfortunately, we're not quite there yet.

As to the blank components, that's just for listing people in a project but not in a component, like for the mdtadmin (
download.eclipse.org/modeling/mdt/) or modeling-home (www.eclipse.org/modeling/) folks. (Everyone's in a component too, but those "not quite component" groups have to be somewhere and that's where I thought they'd make the most sense. 

Speaking with Ed, however, there's another level of indirection that needs to be explained, which is "component bundles" or "combined builds." There are three examples of this in EMF and EMFT. Do not confuse this with "subprojects" as was tried in MDT for the "UML" subproject (which if iirc, was UML-UML2, UML-UML2 & UML-OCL). 

1. The "EMF (Core)" component of the EMF Project, aka emf-emf, aka /cvsroot/modeling/org.eclipse.emf/org.eclipse.emf, includes SDO, which is in a different cvs module (/cvsroot/modeling/org.eclipse.emf/org.eclipse.emf.ecore.sdo), and therefore is a different component, with theoretically different committers. In reality, it's the same people -- Ed, Marcelo, Dave, and me, so we introduce this "metacomponent" concept to allow for groups of components that run together in the wild as a pack, not lone wolves. So EMF (Core) and SDO are listed as two different components on the website, with separate release notes, combined builds (one zip for both EMF and SDO), separate update jars (you can install EMF w/o SDO). But they're also referred to as the same entity in terms of participation in Callisto/Europa/Ganymede, in release reviews, etc. 

2. The second example of this is Christian Damus' "QTV" or "MQ/MT/VF" components in the EMF Project, Model Query (MQ), Model Transaction (MT), and Validation Framework (VF). These, as with EMF/SDO, exist as unique components in cvs, each with unique unix groups, and unique builds. At one time they had several committers on each, but since then it's just one committer for all three: Christian. He produces a combined feature for Europa so that the trio can be installed together as a group to improve the user experience (mostly to help with GMF installation). Builds are done for each of the three separately because some users might want only one or the other (as with wanting EMF but not SDO); features dropped to the Update site reflect this too, as each component has its own SDK and runtime, etc. However, in terms of planning, New & Noteworthy, and release reviews, the trio are considered one "component bundle".

3. The third example is that of Eike Stepper's CDO and Net4j components in the EMFT Project. CDO and Net4j build separately; CDO depends on Net4j (as MT depends on MQ and VF); CDO and Net4j contribute separate zips and update features. But there is only one unix group for both, because there is only one committer for both. Also, because they are related components, they are often referred to as CDO/Net4j, though there has never been any feature bundling or combined builds to date.

Clear as mud? ;-)

So, assuming that we define a component to be "a folder in CVS with source code which will be built and published on the website/update site", then here's the breakdown:

Project    Component    Committers
EMF    EMF    emerks,davidms,marcelop,khussey,nickb
EMF   SDO    emerks,davidms,marcelop,nickb (not sure if khussey is a committer too)
EMF   MQ   cdamus
EMF   MT   cdamus
EMF   VF   cdamus

EMFT    CDO    estepper
EMFT    Net4j    estepper
EMFT    Teneo    mtaal
EMFT    Compare    cbrun,jmusset
EMFT    Search    jlescot,lbigearde
EMFT    JCR Management    sboehme

MDT   EODM    gxie,lzhang,yyang
MDT   OCL    cdamus
MDT    UML2  jbruck,khussey
MDT   UML2 Tools    mgolubev
MDT    XSD    emerks,davidms,marcelop,nickb (not sure if khussey is a committer too)

M2T   JET  jcheuoua,pelder

Or, if you prefer to think of components as bundles of functionality, then:

Project    Component    Committers
EMF    EMF/SDO or EMF (Core)    emerks,davidms,marcelop,khussey,nickb
EMF   MQ/MT/VF or EMF QTV   cdamus

EMFT    CDO/Net4j    estepper
EMFT    Teneo    mtaal
EMFT    Compare    cbrun,jmusset
EMFT    Search    jlescot,lbigearde
EMFT    JCR Management    sboehme

MDT   EODM    gxie,lzhang,yyang
MDT   OCL    cdamus
MDT    UML2  jbruck,khussey
MDT   UML2 Tools    mgolubev
MDT    XSD    emerks,davidms,marcelop,nickb (not sure if khussey is a committer too)

M2T   JET  jcheuoua,pelder

Note also that in reviewing the database export output I notice I have jbruck listed as an XSD committer which I believe is wrong? I also see a lot of "NULL" values that should be removed. (That's my bad.)

As an aside, and in the interest of full disclosure, I see myself listed in a lot of places where I was never portal-vote-authorized, but *was* PMC- or component-lead-authorized (and therefore Webmaster authorized, too), solely for the purpose of setting up builds and doing other releng maintenance work. So, this is accurate in terms of filesystem access, but not should not be seen as true component committership (in the voted-in-by-portal sense), which is why I don't list myself in many places above. (I've also omitted the .releng "components"; they include the same committers as their sister component, plus nickb.)

For example, I have group access to MQ, MT and VF (emf-query, emf-validation, emf-transaction), though I was never voted in as a committer, and have never contributed any java code. (On the flip side, Christian used to be in group emft-releng and contributed fixes to EMFT's common releng code, though he was never voted in to that role either.) Having group rights simply allows me to fix build-related meta, like 
feature.xml and MANIFEST.MF files, and I've never abused this power to sneak my own edits into the code because frankly, I don't understand it well enough to want to. This has also allowed me to be able to do work that would otherwise have required the Webmasters' time, such as CVS module migration from /cvsroot/tools or /cvsroot/technology to /cvsroot/modeling, or would have wasted two people's workday -- submit a patch, wait for it to be committed, run a build, test output, submit new patch... sure, it can be done, but it's inefficient from a workflow point of view, and wastes the developer's time when I can be hacking away by myself.

In short, while it's probably a violation of some rule or other, it serves a purpose and helps me do my job more efficiently. Should such rule(s) be changed to allow this workflow optimization? Or could it be argued that this is a case of following the 'spirit of the law' vs. the 'letter of the law'? In the past, with MDT, I've been granted *temporary* access and then when the builds were happily running, that group access was revoked. In MDT, I apparently have ACL access to creating files in /cvsroot/modeling/org.eclipse.m2t/, though I'm not in group m2t-dev. Truly, there's something odd going on there.

As everything I do is logged in CVS, none of this should be a huge surprise to anyone, the EMO included. With Search CVS, you can see all 35,500 edits I've done in CVS since 2004: 
http://www.eclipse.org/modeling/emft/searchcvs.php?q=author%3Anickb&p=1423

Anyway, all these issues will hopefully be fixed one day when we close on 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=198541, "Standardized groups on dev.eclipse.org", though I admit it's cool being in the top three "people with more than 16 groups/ACLs": 
https://bugs.eclipse.org/bugs/attachment.cgi?id=76505 ;-)

If anything posted above is inaccurate, erroneous, or just plain wrong, please correct it with my apologies. If I've missed anyone, it's not intentional -- you can reopen bug 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=182613#c11 with corrections or addenda. And if I'm in deep sh!t for admitting to these "deviations from the Eclipse Way", then I throw myself at the mercy of the court and beg for leniency. ;-)

Nick

On 9/13/07, Bjorn Freeman-Benson <bjorn.freeman-benson@xxxxxxxxxxx> wrote:

Ah, I didn't realize that your tools was so nifty. Ok, no problem. Well, two problems/questions:

1. You really want your components to be named "org.eclipse.emf.ecore.sdo" and not just "ecore.sdo"?
2. You seem to have some blank component names - that doesn't work with the database. Perhaps you'll want something like "root" or "core" for those?
   

- Bjorn

Nick Boldt wrote:

Bjorn:

The last time you asked for this data you wanted it in tabbed text format, which is exactly what you get with the tool I built for you.

http://www.eclipse.org/modeling/emft/project-info/team.php?export=project,component,committerid