On Mon, 19 Jan 2015 20:34:23 +0100, Torsten Curdt wrote:
...and it's still the term we are using:
http://commons.apache.org/components.html
You miss my point(s): It's totally clear what a component is,
as defined by "Commons". The issue is how it relates to the
"Commons project" management.
That does not sound like "totally clear" to me. That sounds like a
question.
For whatever reason it feels like you are a bit hung up on the term.
I merely wanted to point out that we've been using this term for a
while now.
...and your query should probably also have listed that link.
It did, of course; but I wanted to find _another_ "Apache project"
where the community is quite split, code-wise.
Forget the term for now. It's irrelevant for this discussion.
Öne point is that the "Commons project" releases _independent_
components (cf. the other post); there is no relationship
whatsoever between the components.
There is the build system for some, for some it's the people - be it
just for oversight. And then there is the PMC and the board reports.
Of course, there are some _administrative_ connections; it's very
helpful to have a home for projects that by themselves wouldn't have
the resources to handle all the management chores.
Claiming there is no relationship is a very code centric point of
view
Of course it is; because the fundamental, crucial, central point is
indeed that one: not everyone can (as in "is able", or "has the time",
or "is interested") work on many components.
There are more than 40 components in "Commons".
How many active contributors?
How many write code for more than 3 components?
How many vote for any one component during the release process?
IMHO, there are no more than 5 people (at any one time the real
count is probably closer to 2) who could claim they really oversee
the "Commons project" as a whole as would be mandated by policy.
It's obviously not true that all the PMC members oversee the
whole project.
- and frankly speaking a little concerning.
Why?
Everything said and done here is related, in one way or another,
to code.
I agree - commits and jira notifications can be a lot of traffic. But
just the dev list on it's own is so little traffic that I am having
trouble understanding why we are having this discussion at all.
I already mentioned that "dev" was not the main problem, although
it is understandable, and I've said it too, that some "little"
(programming) project's contributors might want to start benefiting
from a home at Apache without being forced to contribute to all
the Commons (programming) projects.
By letting them in with limited expectations[1], the community may
grow later on, as a side-effect.
With oversized expectations (dictated by a policy that may not be a
perfect to a project like "Commons"), the community scares people
away (contrary to the many times stated goal).
Why not keep the one dev list, you unsubscribe from the commits ML
and
keep track of issues and commits through github and jira directly?
Could that work?
Maybe[2] but it is _contrary_ to the policy!
Regards,
Gilles
[1] And _code_ quality is the one expectation on which we can't be
flexible, because if the newcomers finally go away, it is on the
rest of us that the burden will fall.
[2] I never used "github".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
