On Sat, Mar 22, 2008 at 1:42 AM, Russel Winder <[EMAIL PROTECTED]> wrote: > Henri, > > > On Fri, 2008-03-21 at 19:14 -0700, Henri Yandell wrote: > > > We need to get the damn thing out. :) > > I think it is also worth having someone actively working on this who is > part of the commit team.
Definitely no one disagreeing with that there. > I appreciate there are zillions of trendy new > annotation-based packages, but there is a role for a builder-based > package, and it would be good if Commons CLI was the acknowledged de > facto standard. To do this it need to be steadily active as a project. > This means one or two people committed to processing issues as and when > they arrive. Agreed. 3 of the 16 issues in 2.0 have unapplied patches to look at, though two are really a combination: CLI-61, CLI-144, CLI-145 (test part). > Starting mid-April I can get back to having a look at Commons CLI2 for > Groovy and Gant, which is likely to create a sequence of issues. As > long as there are a few people working on it there is a small community > who can keep the energy going, then I think it may be possible to > breathe life back into Comons CLI. My experience is that if you are active, others will be active. For any community (or subcommunity in this case), someone needs to supply the heartbeat. A steady stream of commitment. That's been the problem for CLI, lacking that defined heartbeat. > My work practice will be to take a branch of Commons CLI using either > Bazaar or Git -- I don't think Mercurial has proper Subversion support > as yet, so is not an option. This will almost certainly be a branch > without previous history to avoid having to process 639959 commits! I > will then keep a Subversion Head mirror and a personal branch of changes > to create patches. I would publish these branches and cross merge with > anyone else actively working on this. So this solves the problem of > needing Subversion commit access to progress. However, it does require > someone with commit access to triage and process patches on an active > basis. As long as it ends up being atomic patches in the JIRA; any work practice is great :) > > > i would volunteer to work on the issues that prevent a release. > > > > In no particular order: > > > > * Solve, or recommend moving to 2.1, all the 2.0 issues in JIRA. > > Commons CLI Trunk Head compiles and installs to my local Maven > repository just fine using Maven 2, i.e. "mvn install" does exactly what > it should. The problem I guess is knowing what is 2.0 and what is 2.1. > As an outsider looking in without looking too hard I would say there is > 2.0.0-SNAPSHOT and nothing else. They're versions in JIRA. 2.0=fix before release, 2.1=fix after release. > > * Make sure M2 is happily building the site, distribution etc. > > I am checking the site building, but it is going to take a while as it > seems to need downloading half the universe of all jar files :-( > > > > * Make sure the checkstyle/pmd/findbugs aren't full of problems. > > Pass on this I'm afraid, I am not sure what needs to be done. I build the site under m1 and then look at the reports. Found one nice bug with findbugs tonight, other noise to fix, like should the Comparators implement Serializable, and should Option because it's in an Exception. Lots of checkstyle noise, but because the style isn't set yet. PMD has nothing, which is good. It's usually the most important one to get zero'd out. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
