Re: [modeling-pmc] How to Mange Modeling Subprojects

[Kenneth Hussey <khussey@xxxxxxxxxx>]

Ed,

I agree we should have a common policy
for all Modeling projects, and I'm mostly happy with your proposal. Regarding
the addition(/removal) of components to projects, however, I'm inclined
to go with the latter - all the committers on the project (from all of
its various components) should have a collective say in what they feel
is best for the project as a whole...

Cheers,

Kenn Hussey

Senior Software Developer
Rational Software, IBM Software Group

770 Palladium Drive
Kanata, Ontario, K2V 1C8

T: (613) 599-3980  F: (613) 599-3912

Ed Merks/Toronto/IBM@IBMCA
Sent by: modeling-pmc-bounces@xxxxxxxxxxx

02/02/2007 08:48 AM

Please respond to
PMC members mailing list <modeling-pmc@xxxxxxxxxxx>

To	modeling-pmc@xxxxxxxxxxx, emf-dev@xxxxxxxxxxx, emft-dev@xxxxxxxxxxx
cc	Bjorn Freeman-Benson <emo@xxxxxxxxxxx>
Subject	[modeling-pmc] How to Mange Modeling Subprojects

Hi,

I know we've talked about this subject before so let me start by saying
(for Bjorn's benefit) that I know subprojects don't have subprojects.  :-)
With EMFT and EMF merging and with new EMF components soon coming on-line
(e.g., the model workflow engine, and the compare framework)  I want
to be
sure that we define and follow a well-thought-out process that does not
conflict with what the foundation considers "good practices".
   In other
words, what I'd like to do is continue as I have been doing with EMFT.
I.e., I'd like to manage EMF as a collection of separate components, much
like a top-level project has separate subprojects.   Each component
will
have a component lead and a collection of additional committers.  There
will be a CVS module for all the source code for that component.  
Only the
committers for that component will have access to that CVS module.  When
a
component wants to add new committers, only the committers for that
component are involved in the vote and only their collective vote is
considered relevant.  As such, EMF will be a collection of relatively
independent components, each with autonomy to control their own component
as they see fit (within the constraints imposed by the foundation).  
For
EMF, we will use a common newsgroup and each subproject will synchronize
its common builds and releases to provide a cohesive build/release stream
for downstream consumers.

Does this all sound fine?  It seems like this is something we should
codify
explicitly so that there is no room for confusion and no cause for
complaints later.  Probably the MDT project and other Modeling subprojects
should be similarly organized, so codifying this for all the modeling
subprojects probably makes sense (though some projects might well consist
of just a single component, at least initially).   I'm particularly
concerned about the MDT project, because that's where XSD is moving (has
moved), and I don't consider that move as something that suddenly grant
rights to other MDT component committers to determine,  for example,
whether the existing XSD committers can add a new committer.  One
issue
that still seems to be dangling, is who decides whether a new component
can
be added and what the initial set of committers for that component should
be?  Should it be just the project lead or the collective vote of
the
committers from all the components?  I tend to think it should be
the
former but don't have any big concerns about it being that later...

Does anyone have opinions or suggestions?  Silence will be interpreted
as
complete agreement. :-)


Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265  (t/l 969)


_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc