On 3/4/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
> On 3/3/06, Henri Yandell <[EMAIL PROTECTED]> 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.
> >
> <snip/>
>
> For starters:
>
> * Do we need a volunteer to call a vote for [latka], move it to
> dormant if vote passes etc.?
I'll continue to follow this up. My itch to code at Commons is
superceded by my itch to organize - in so much as that organizing
doesn't get irritating.
> * 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.
Will come up with a list of ones to consider for proper-dormant
(whatever we call it).
> * Seems there is interest in pulling [modeler] under Tomcat,
> post-TLP, so what do we need to do to encourage that? ;-)
This is a definite issue to discuss a lot. The point of Commons is for
other projects to share their components here - however, if no one is
sharing it and it's only being used by one project, is that cause for
it to move back to the original TLP?
> > 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.
> >
> <snap/>
>
> 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.
m1.1 is an upcoming issue too :)
> > 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.
> >
> <snip/>
>
> 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*.
I'm definitely thinking foundation-wide on the suggestions, rather
than Commons-specific. We like to say that it's nice not having
jakarta in the package name as it allows TLPs to happen more easily -
but that is a short term thing, we can't continually be a TLP
incubation system. At some point we won't be promoting projects
upwards and that reason will have gone.
> > We have a sprawling site that could be much better - though this is
> > entirely my opinion.
> >
> <snap/>
>
> 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).
My site issues are information-architecture/design issues - I think
it's too noisy and big, in many places we don't pay attention to user
manuals but spend too much space on the basic info and we don't treat
the documentation properly in releases. The cop-out is to have a site
per release, but that's ignoring the issue that our sites and
documentation are intermingled.
> > 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.
> >
> <snip/>
>
> 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".
This one is more repeating complaints I've heard from people who
struggle to get involved with Commons. I do think it's a problem on
getting people involved - Commons should be the easiest project to get
involved in as the codebase is very modular and you don't have to
understand a big huge design. However the mailing list is detrimental
to the newcomer to open-source, it's not a nice one to make your first
subscribed mailing list.
No idea on solutions though. Maybe we just acknowledge that newcomers
to open-source aren't the target audience and focus on committers of
other projects.
> > 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.
> >
> <snip/>
>
> Commons or Web Components, as appropriate?
Web Components would be a grouping in a unified Commons/Jakarta :)
> > 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.
> >
> <snip/>
>
> 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.
First step - buy a usb key and get PGP setup on my Mac to point to it.
Some old memories that releasing on Macs was problematic (Java-wise),
but hopefully that's old news.
Second step - volunteer to do releases. SCXML getting close then?
> > We've recently raised issues in managing the sandbox promotion/failure
> > cycle.
> >
> <snap/>
>
> 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.
Current state is that at 6 months old a component gets voted on dormancy.
I need to start putting time into Commons documentation - now that
time has freed up.
Also doing a Commons exhibit at EclipseCon in a few weeks - should
post on that in a bit, see what we think I should be doing.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
