commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <flame...@gmail.com>
Subject Re: Problems...
Date Sun, 05 Mar 2006 08:21:44 GMT
On 3/4/06, Brett Porter <brett@apache.org> wrote:
> Stephen Colebourne wrote:
> > Yes we have many, many problems.
> >
> > CI
> > How does another thing to worry about help us. Why not focus on Gump?
>
> Paying attention to gump and keeping it up to date would be good for
> commons as it will help monitor the library externally. That doesn't
> really directly help the project but its good to know if the false
> positives don't drown them out.
>
> Honestly, I think CI for commons should be a little lower on the list of
> things to do. Currently, work is being primarily done by a single person
> at a time which doesn't really need it as much. If it is there, it would
> be useful to use, but no point pushing on it until it is.

Agreed that it's not a top level priority; though itches vary.

My itches:

* Getting Craig's scripts off his back
* Auto-deploy of snapshots to ASF Maven snapshot repository
* Usefully up to date Maven reports (latest source, junit reports,
code coverage etc)

> > My analysis is that its time for a bit more radical surgery. And I mean
> > splitting commons into smaller communities. Jakarta Xxx Components sets
> > the naming pattern. If we do this, then each new group will be small
> > enough to be able to take decisions by itself, for example on the site.
>
> The re-Jakarta-isation of Jakarta? :) I thought the whole purpose was to
> get rid of the silos, not start building more.
>
> This is essentially the problem. Commons needs to decide if it is a
> bunch of independent components, or an ecosystem where all the
> components are a part of a single project.

s/Commons/Jakarta, but agreed.

The latter (ecosystem) fits the style of an Apache project. The former
needs a lot of thought into just how to pull it off - it's yet another
umbrella, so we'd need to argue for it, convince people it can fit
inside the asf and look at the incubator and the asf to see how they
did umbrellas.

My overly dramatic view is that Jakarta is a corpse pulling down its
constituent parts - much of whic is due to the independent
subcommunities and large lack of a Jakarta community. We'd want to
avoid replicating that in Commons.

> That's not to say there should be separate lists. We've done that for
> big subprojects in Maven and it works just fine. People with special
> interests can go there, but all the people active across projects hang
> out and discuss on the main dev list.

That would work less well in Commons. As far as I understand, the
Maven sub parts are all very much formed around the Maven concept and
codebase - ie) I presume the object model for a pom pervades all of
the subprojects and unifies them. Commons would have only
infrastructure and rules to unite if the mailing list were split - not
code.

We/ASF like to talk about the community a lot, but I'm a firm believer
that it's the community and the code. They reflect and feed on each
other. The best way to keep the community together, is to keep them
dependent on the same piece of code.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message