commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject Re: Problems...
Date Sat, 04 Mar 2006 17:22:36 GMT
On 3/3/06, Henri Yandell <> wrote:
> Taking a step backwards. What are the current problems besetting
> Commons? I'm probably getting ahead on myself on trying to organize
> solutions without consensus on problems.
> We have an inactivity issue, and reflecting that inactivity to the
> users. To solve the latter we've added the dormant concept to the
> Sandbox, and need to do something similar to the main projects.
> Jakarta as a whole has these problems and I'm looking to Commons for
> the solutions. On the former, we've given ourselves a mental wake up
> to get people involved, patching and committing.

For starters:

 * Do we need a volunteer to call a vote for [latka], move it to
dormant if vote passes etc.?

 * We should do the same for [el]. JSP >= 2.1 seems like it will be on
a separate el track for Tomcat, its biggest "beneficiary", so probably
sensible to move it to dormant too.

 * Seems there is interest in pulling [modeler] under Tomcat,
post-TLP, so what do we need to do to encourage that? ;-)

> We've got an experimental m2 build in the sandbox, and a couple of
> components which don't have an m1 build. How independent do we want
> components to be. I'm thinking less independent because I want to
> maximise the ease with which people can move between components (to
> deal with inactivity), but the community might want to go the other
> way and be far more bazaar like.

IMO, until any further consensus, *all* {proper,sandbox} components
should have a {m102,xdoc192} build. Anyone is welcome to make progress
on the m2 side if they wish, but not having a m102 build just makes
those components "unavailable" for anyone who doesn't want to deal
with m2 yet.

> We have releases going out without our awareness. The commons-cli
> issue to the maven repository a while back; Jakarta had a similar one
> with velocity-dvsl. That's a general Apache problem that I'm
> suggesting solutions to on repository@ and letting what I'm saying
> here be affected by that (which probably makes me seem more illogical
> than usual) - this is one of the reasons why I'm in favour of a
> general Apache solution to group-ids.

Your suggestions on repository@ seem well thought-out, but I see both
sides of the groupId issue -- while it will make repo management
easier, Maven folks don't necessary seem to care, there is the added
element of confusion to users by the injection of jakarta in the mix
-- *sigh*.

> We have a sprawling site that could be much better - though this is
> entirely my opinion.

This is the least of my concerns. Like Martin, I don't have any
trouble with the site, I stick to the book. But unlike Martin, I've
built quite a few sites lately (ofcourse, there may still be some
sites that are troublesome, it will be nice to know what the exact
issues are -- apart from not heeding the correct versions of
maven/plugins to build).

> We have a very noisy set of mailing lists. Need to ask how the Jive
> forum is going for Struts (I think I heard that was in place?).
> Watching how the Maven-dev move to separate lists for commits, jira,
> dev, ci goes.

Personally, not a concern, I like it this way. Again, perhaps
articulate how and what "noise" bothers you? I don't use forums, posts
from them tend to become noise to me (things such as loss of
formatting, loss of appropriate "history" before posting bother me).
Ofcourse, anyone can use whatever tools makes them most productive
(one of the key arguments for forums I've heard), likewise recipients
reserve the right to only read email that they find "readable".

> We have a need to organize our CI. Apparantly the hold up there is
> twofold:  1) issues over a general build server, or whether it should
> be individual pmcs  2) the zones machine is busy cpu wise and Infra
> don't want us to have a Commons zone that builds a lot just yet.
> The PMC Chair is casting random solutions to Jakarta's oversight and
> community issues and suggesting Commons can absorb Jakarta (apart from
> the bits that leave) as a solution.

Commons or Web Components, as appropriate?

> Lack of release management. I'm getting over my PGP whining and am
> going to dig in and start volunteering to do some releases again.

If you're digging in, you're welcome to take a quick (or lasting ;-)
look at [scxml], I'm looking for general opinions about it.

> We've recently raised issues in managing the sandbox promotion/failure cycle.

I think we've become increasingly particular about sandbox promotion,
and correctly so. I also think we should perhaps cap the sandbox stay
for a component, lest it be left at "almost promoted" state forever.
That doesn't help anyone.


> Hen

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message