commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject Re: [all] releases
Date Tue, 05 Dec 2006 05:20:30 GMT
On 12/4/06, Henri Yandell <> wrote:
> Updating this thread; Digester, DbUtils, FileUpload and Discovery are
> now all released. That leaves us with:
> * Logging 1.1.1 - I see 3 fixed issues in JIRA and nothing left to do.
> However there are 7 issues without a version which might mean they've
> not been looked at.
> * IO 1.3 - 1 issue to be resolved and then we can release.
> * FileUpload  1.2 - 1 issue to be resolved - blocked by IO 1.3. 7 unversioned.
> * Betwixt 0.8 - In the release process. Versions don't seem to be
> actively used in JIRA.
> BeanUtils is a fair way away, SCXML sounds like it'll be in a couple
> of months, Lang needs to decide if it should target 2.3 or 3.0 and
> start churning. DBCP 1.2.2 sounds like it getting closer and closer, 1
> issue in 1.2.2, but 11 still unscheduled. Afaik, Pool is at the
> revolution stage, unless DBCP requires a minor release.
I am cleaning up in prep for DBCP 1.2.2 - the only remaining issue
will be closed when the release is cut, since it is just dropping
collections dependency.  I also need to either get a brilliant idea on
the deadlock bugs now pushed to 1.3 (probably using new [pool] impl)
or figure out a way to add appropriate warnings to the doc and release

> Any others getting close?
> Validator and DbUtils are now back at the beginning of new dev
> releases. Discovery and Attributes are 6 foot under (I hope :) ).
> ----
> [off on a tangent]
> The unversioned-and-possibly-not-looked-at bit above is due to how I'm
> reading the JIRA projects.
> An issue coming in has 4 possible answers:
> 1) Put it in the currently working on version.
> 2) Put it in the next version. This is an acknowledgement that it's a
> problem, or that it's an enhancement that shows merit; but not a
> guarantee that it will go in that version. It's both 'next version'
> and 'someday'. Comments to the effect of "unit-test + patch and we can
> push it up to [current-version]" might be suitable.
> 3) Say "No" by resolving it wontfix etc.
> 4) Comment. This is a conversation with the aim of achieving one of 1, 2 or 3.
> I think this is a very low-energy, high-return way to manage our
> components.

The problem that I keep running into when I try to do this is that it
takes a fair amount of work to distinguish between 2) and 3) or to
meaningfully do 4).  Could be I am just slow.  I agree that getting
some kind of response is good.  I am not sure I agree, however, with
trying to jump to assigning fix versions before doing some work to
understand what the issue is, or if there is in fact an issue at all.
I just bounced a [dbcp] issue to OJB, for example, after spending a
little time figuring out that it was in fact the [pool] config doing
what OJB set it up to do by default that was causing the user problem.


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

View raw message