| RE: [tools-pmc] RE: [ve-dev] Contribution on VE with XML editor |
|
Thanks Doug. I wasn’t detailed enough in my response. The problem is
not that we can’t have separate committers for components, and we
already do that. The issue is that we have a pretty high bar for being a
committer on the core Mylyn project. In an incubator project we could have a
lower bar for making contributors committers. For those interested in the details: A concrete example of this issue
is Helen of CodeGear, who has contributed the XPlanner connector to Mylyn. In
terms of a code contribution, this was big, and all her participation in the
project has been great. However, the XPlanner connector is an Incubation
quality component in our Sandbox, there has been little community feedback, and
only 10 bugs have been fixed on it (http://www.eclipse.org/mylyn/contributors/).
Until there are considerably more user-reported bugs fixed on this component I feel
unable to nominate Helen for commit rights, because I don’t yet have
enough indication that this component will have the community adoption needed
to bring it out of Incubation status. So in spite of her great work I haven’t
nominated Helen for commit rights yet, and I would have done so if we this were
an incubation project. At some level this is splitting hairs, because if I
considered Components to be more primary then I should be fine with nominating
her. In other words, I’m a bit confused about how primary a unit the
Component is vs. a Project, and the fact that only projects can have a parallel
IP process currently seems to be a deciding factor. So I’ll be curious
to see whether this is changed, because I certainly see arguments for keeping
everything under one project umbrella, and am sure that if we create a Mylyn
Technology project we will cause some end user confusion. Mik From: Doug Schaefer
[mailto:DSchaefer@xxxxxxx] Cool, thanks Mik. BTW, projects can have components and the components can have
different sets of committers. You should be able to do this for your sandbox
components. Doug
Schaefer, QNX Software
Systems From: tools-pmc-bounces@xxxxxxxxxxx
[mailto:tools-pmc-bounces@xxxxxxxxxxx] On Behalf Of Mik Kersten Just fyi, this is pretty much how Mylyn operates. We
haven’t yet bitten the bullet of creating another project, but for the past
couple of years we’ve had a separate set of Sandbox components where we
incubate things. While we don’t have the benefit of the parallel IP
process, this does give us the ability to communicate Incubation status on
those components, given them their own update site, project set, etc. In addition to the lack of parallel IP process, which is
probably the biggest benefit of incubation, the thing that’s I’ve
been finding most awkward about the single project approach is that the
incubation components don’t have their own set committers, as they would
with a separate incubation project. Bjorn made some other good
points about the split project approach here: http://eclipse-projects.blogspot.com/2007/09/getting-new-people-started-in-your.html
Mik From: tools-pmc-bounces@xxxxxxxxxxx
[mailto:tools-pmc-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer Incubator components would make
sense. Having to recreate the project structure, even if it is the same people,
is where I have issues. Also the façade that they are two separate projects is
misleading to the community since operationally they are not. Projects in my
mind are organizational things, i.e. the people. Is it the code that’s
incubating or the people? |