On 12/4/06, Henri Yandell <[EMAIL PROTECTED]> 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
notes.

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.

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to