You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <fl...@gmail.com> on 2006/12/05 01:07:49 UTC

Re: [all] releases

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.

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. One of my todos is a weekly report that lets us know how
many issues are in which state in the jira projects; and how many new
ones there are that week etc. Also it should highlight ones that need
a release [X resolved for an unreleased release and nothing unresolved
-> possible-release!].

Any thoughts?

Hen

On 11/17/06, Henri Yandell <fl...@gmail.com> wrote:
> This is cool - we're active enough that our internal dependencies are
> now important for release prioritizing. Sure a pain - but a good sign
> of activity.
>
> So, here's the ones I know of:
>
> Logging 1.1.1
> Digester 1.8
> IO 1.3
> Betwixt 0.8
> DbUtils 1.1
> FileUpload 1.2
> Discovery 0.4
>
> Any missing?
>
> Seems that logging 1.1.1 is a blocker for digester, betwixt and
> discovery; and IO is a blocker for fileupload. And digester is a
> blocker for betwixt.
>
> So sounds like we should get logging 1.1.1 out asap, IO 1.3 out soon,
> dbutils can go whenever. ???
>
> Is it worth thinking about things like this?
>
> Hen
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [all] releases

Posted by Phil Steitz <ph...@gmail.com>.
On 12/4/06, Henri Yandell <fl...@gmail.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [all] releases

Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/6/06, Dennis Lundberg <de...@apache.org> wrote:
<snip/>
>
> There is also an import fix that makes it possible to use JCL in applets
> again. We had to revert back to 1.0.4 because of that bug. I want to
> verify this fix, but don't have the time right now. Perhaps this weekend...
>
<snap/>

Seems pertinent (Mark did try the nightlies for this):

 http://marc.theaimsgroup.com/?t=116550352600005&r=1&w=2

-Rahul


> --
> Dennis Lundberg
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [all] releases

Posted by Dennis Lundberg <de...@apache.org>.
Dennis Lundberg wrote:
> Craig McClanahan wrote:
>> On 12/4/06, Henri Yandell <fl...@gmail.com> 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.
>>
>>
>> I have reviewed the JIRA comments on the seven unversioned issues, 
>> although
>> I have not looked at the  proposed patches.  All of them have had 
>> extensive
>> discussion (although none very recently), and seem to have a variety of
>> concerns noted in the comments.  None of the issues strike me as 
>> things that
>> are urgently needed for a 1.1.1 release, although it makes sense to 
>> look at
>> them in the context of a 1.2 or 2.0.
>>
>> That being said, one of the fixes currently in the trunk was to fix the
>> botched Maven metdata that did not declare the various logging
>> implementation libraries to be optional.  This causes a lot of pain 
>> for C-L
>> 1.1 users who build with Maven, and therefore (in my book) justifies a
>> 1.1.1release sooner rather than later.
>>
>> *That* being said :-), I don't have time to be RM for this, so I'm just
>> hoping someone is willing to pick up that ball, and that the other
>> developers agree with my assessments above.
>>
>> Craig
> 
> There is also an import fix that makes it possible to use JCL in applets 
> again. We had to revert back to 1.0.4 because of that bug. I want to 
> verify this fix, but don't have the time right now. Perhaps this weekend...
> 

I can now confirm that JCL 1.1.1 built from SVN trunk works in our 
applets under Java 1.5, where the applets previously failed to start 
because of a java.security.AccessControlException that was thrown by JCL 
1.1.

-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [all] releases

Posted by Dennis Lundberg <de...@apache.org>.
Craig McClanahan wrote:
> On 12/4/06, Henri Yandell <fl...@gmail.com> 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.
> 
> 
> I have reviewed the JIRA comments on the seven unversioned issues, although
> I have not looked at the  proposed patches.  All of them have had extensive
> discussion (although none very recently), and seem to have a variety of
> concerns noted in the comments.  None of the issues strike me as things 
> that
> are urgently needed for a 1.1.1 release, although it makes sense to look at
> them in the context of a 1.2 or 2.0.
> 
> That being said, one of the fixes currently in the trunk was to fix the
> botched Maven metdata that did not declare the various logging
> implementation libraries to be optional.  This causes a lot of pain for C-L
> 1.1 users who build with Maven, and therefore (in my book) justifies a
> 1.1.1release sooner rather than later.
> 
> *That* being said :-), I don't have time to be RM for this, so I'm just
> hoping someone is willing to pick up that ball, and that the other
> developers agree with my assessments above.
> 
> Craig

There is also an import fix that makes it possible to use JCL in applets 
again. We had to revert back to 1.0.4 because of that bug. I want to 
verify this fix, but don't have the time right now. Perhaps this weekend...

-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [all] releases

Posted by Craig McClanahan <cr...@apache.org>.
On 12/4/06, Henri Yandell <fl...@gmail.com> 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.


I have reviewed the JIRA comments on the seven unversioned issues, although
I have not looked at the  proposed patches.  All of them have had extensive
discussion (although none very recently), and seem to have a variety of
concerns noted in the comments.  None of the issues strike me as things that
are urgently needed for a 1.1.1 release, although it makes sense to look at
them in the context of a 1.2 or 2.0.

That being said, one of the fixes currently in the trunk was to fix the
botched Maven metdata that did not declare the various logging
implementation libraries to be optional.  This causes a lot of pain for C-L
1.1 users who build with Maven, and therefore (in my book) justifies a
1.1.1release sooner rather than later.

*That* being said :-), I don't have time to be RM for this, so I'm just
hoping someone is willing to pick up that ball, and that the other
developers agree with my assessments above.

Craig