I'm hoping to push a [net] release out by xmas...too busy at the moment to look at it, but will have some free time in a couple of weeks. R
"Jakarta Commons Developers List" <commons-dev@jakarta.apache.org> wrote: > > 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] > > ----------------------------------------------------------------- Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
