As such, I
am
comparing the cost for a committer on an existing project to add a new
plugin
to that project vs. creating a new Eclipse project to hold that plugin
(because
it’s functionality that would be useful to others). In both of those
cases, the running overhead is the same. It’s the startup overhead that
discourages this kind of code sharing from taking place.
Yes, you're correct that creating a new project to hold a new plug-in
is more work than adding committers to an existing plug-in. I don't
really know what to say about that other than "talk to the committer
reps about changing the dev process": the dev process is what it is and
it's the way it is mostly because the Board wants it that way.
Regarding
constraining projects, I cannot
even begin to comprehend why this would be a benefit to the community.
Well there's an obvious benefit to the community in that the Legal and
Webmaster teams have only N people and they can only support M
projects. Having >>M projects will cause everyone to suffer from
delays... But that's sort of a minor point... The larger point is,
again, the Board said they wanted it that way.
But, anyway, I'd still like to work on making the starting of new
projects earlier.
- Bjorn
|
