You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by James Carman <ja...@carmanconsulting.com> on 2013/10/06 20:30:36 UTC
[DISCUSS] Mission Statement for Commons...
All,
The Apache Commons project seems to be languishing as of late and we
need some rejuvenation. Perhaps we should try to define our mission
as a project. What are our goals? What do we want to accomplish?
Who are our users/customers? What non-functional qualities do we want
our software to exhibit? How do we want to conduct ourselves? How
often do we want to do releases? What else?
Sincerely,
James
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by Phil Steitz <ph...@gmail.com>.
On 10/6/13 11:30 AM, James Carman wrote:
> All,
>
> The Apache Commons project seems to be languishing as of late and we
> need some rejuvenation. Perhaps we should try to define our mission
> as a project. What are our goals? What do we want to accomplish?
> Who are our users/customers? What non-functional qualities do we want
> our software to exhibit? How do we want to conduct ourselves? How
> often do we want to do releases? What else?
I would say the first two paragraphs under "The Commons Proper" on
the home page [1] state what I have always understood our mission to
be - basically to be a place where reusable Java components are
developed @apache.
We have always really been a loosely federated group of
subcommunities around the individual components, with a fair degree
of autonomy among them. I have always personally liked that. Other
than things like the commons parent pom and the PMC itself, the
individual components aren't bound by too many rules or
standardization. What exactly the components need to do depends on
the component and how often releases are cut depends on the level of
activity on the component and/or needs of users.
Our users come from all over the place - inside the ASF and
increasingly outside. Our main goal should be to attract more of
them into sustained contribution to the components. This is hard in
some cases because there is little / no activity on some components
and in some cases we make it harder than it should be for users to
get involved even on the components where there is active
development going on.
I think we would benefit most from three things at this point:
0) Agreeing on what components are dormant and marking those as such
1) Getting a clear understanding of what the real and perceived
barriers are for getting involved as a contributor (note this is not
the same thing as "getting patches committed" though the two are
related)
2) Finish fixing and documenting the build and deployment process so
that cutting releases is easy
OK, that is about my 2c worth :)
Phil
[1] http://commons.apache.org/
See also: http://commons.apache.org/charter.html
>
> Sincerely,
>
> James
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by sebb <se...@gmail.com>.
On 8 October 2013 21:11, Gary Gregory <ga...@gmail.com> wrote:
> On Tue, Oct 8, 2013 at 2:11 PM, sebb <se...@gmail.com> wrote:
>> On 8 October 2013 17:36, Gary Gregory <ga...@gmail.com> wrote:
>>> On Oct 8, 2013, at 10:09, James Carman <ja...@carmanconsulting.com> wrote:
>>>
>>>> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>>>>>
>>>>> That's not the issue. We want to avoid unresolvable incompatibilities in
>>>>> transitive dependencies. Our components are used by many projects, an
>>>>> incompatibility could render impossible the use of two components
>>>>> together, and you are stuck until the components are updated to use the
>>>>> same version of the common dependency.
>>>>>
>>>>> ASM and BouncyCastle are two examples of widely used projects that don't
>>>>> care at all about the compatibilities, and this is causing pain and
>>>>> wasting time to a lot of smart people.
>>>>
>>>> I think you misunderstand my intent. We have left out features before
>>>> (ones that folks blogged about and said they liked) because a user
>>>> could do something stupid with it.
>>>>
>>>> What you're talking about is "jar hell" and we have already addressed
>>>> that with our naming convention for major release bumps (changing
>>>> artifactId and package name). I'm cool with that idea and I think
>>>> it's a pretty good approach. I don't see anyone else doing it, which
>>>> is interesting.
>>>>
>>>
>>> Yep, our approach works. You cannot be kind of binary compatible, it's
>>> all or nothing.
>>
>> Yes and no.
>
> You can't tell me with a straight face that binary compatibility is
> not a strict true/false attribute ;)
>
> While I agree with the overall feel of your message, my experience
> makes be love BC. Even small apps that end up with layers of 3rd party
> jar deps leads you immediately to jar hell if there is no binary
> compatibility within packages. This is why our change of package name
> (and maven coords) guideline works so well.
>
> Sure, some corner method is a tucked away class may never be used
> outside the jar, but, if it's public, don't break it. You just do not
> know what call sites are going to do.
Each incompatibility needs to be decided on its merits.
For example, if a class or method is clearly documented as internal or
experimental, then anyone that relies on it should not be surprised if
problems occur. Just the same as if one uses a class from a sun.*
package.
There are other examples where the field or code may be part of the
public API, but nevertheless making use of it is clearly wrong.
For example, writing to an entry in a protected final array which
contains constants. (The array should have been private with an
accessor).
I'm sure there have been other cases.
> I have no problem bumping major versions., package names, and Maven
> coords in order to keep a project evolving at 21st century speeds.
I prefer that to jar hell and/or stagnation, however the downside is
additional work downstream.
The choice is not always black/white.
> This is probably why I am OK with a stricter BC definition.
>
> Gary
>
>
>>
>> Yes, one can say unambiguously that a particular change is - or is not
>> - binary compatible according to the Java compatibility rules.
>>
>> But it may still be OK to break binary compatibility without package
>> renames if the likelihood of it affecting end users is extremely low.
>>
>> I think the way to approach binary incompatibility is as follows:
>> - check whether it's really necessary to break compatibility;
>> sometimes it happens by accident and can be fixed
>> - if the break really is necessary, evaluate how likely it is to
>> affect 3rd party code.
>>
>> Depending on the severity of the break, it may be necessary to change
>> package name/Maven coordinates, or it may just require a warning in
>> the release notes.
>>
>> It's not always easy to get this right, which is where it's useful to
>> have a community of experienced developers.
>>
>>> I do like the idea of internal package names like
>>> Eclipse does. This would not stop me from hacking my way in there but
>>> at least I should not be surprised if a minor version breaks internal
>>> binary compat.
>>
>> +1
>>
>> But it's not always obvious initially which classes are which.
>>
>> [Also of course one should start by making everything private
>> (especially mutable fields) and only increasing visibility as needed.]
>>
>>> Gary
>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Oct 8, 2013 at 2:11 PM, sebb <se...@gmail.com> wrote:
> On 8 October 2013 17:36, Gary Gregory <ga...@gmail.com> wrote:
>> On Oct 8, 2013, at 10:09, James Carman <ja...@carmanconsulting.com> wrote:
>>
>>> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>>>>
>>>> That's not the issue. We want to avoid unresolvable incompatibilities in
>>>> transitive dependencies. Our components are used by many projects, an
>>>> incompatibility could render impossible the use of two components
>>>> together, and you are stuck until the components are updated to use the
>>>> same version of the common dependency.
>>>>
>>>> ASM and BouncyCastle are two examples of widely used projects that don't
>>>> care at all about the compatibilities, and this is causing pain and
>>>> wasting time to a lot of smart people.
>>>
>>> I think you misunderstand my intent. We have left out features before
>>> (ones that folks blogged about and said they liked) because a user
>>> could do something stupid with it.
>>>
>>> What you're talking about is "jar hell" and we have already addressed
>>> that with our naming convention for major release bumps (changing
>>> artifactId and package name). I'm cool with that idea and I think
>>> it's a pretty good approach. I don't see anyone else doing it, which
>>> is interesting.
>>>
>>
>> Yep, our approach works. You cannot be kind of binary compatible, it's
>> all or nothing.
>
> Yes and no.
You can't tell me with a straight face that binary compatibility is
not a strict true/false attribute ;)
While I agree with the overall feel of your message, my experience
makes be love BC. Even small apps that end up with layers of 3rd party
jar deps leads you immediately to jar hell if there is no binary
compatibility within packages. This is why our change of package name
(and maven coords) guideline works so well.
Sure, some corner method is a tucked away class may never be used
outside the jar, but, if it's public, don't break it. You just do not
know what call sites are going to do.
I have no problem bumping major versions., package names, and Maven
coords in order to keep a project evolving at 21st century speeds.
This is probably why I am OK with a stricter BC definition.
Gary
>
> Yes, one can say unambiguously that a particular change is - or is not
> - binary compatible according to the Java compatibility rules.
>
> But it may still be OK to break binary compatibility without package
> renames if the likelihood of it affecting end users is extremely low.
>
> I think the way to approach binary incompatibility is as follows:
> - check whether it's really necessary to break compatibility;
> sometimes it happens by accident and can be fixed
> - if the break really is necessary, evaluate how likely it is to
> affect 3rd party code.
>
> Depending on the severity of the break, it may be necessary to change
> package name/Maven coordinates, or it may just require a warning in
> the release notes.
>
> It's not always easy to get this right, which is where it's useful to
> have a community of experienced developers.
>
>> I do like the idea of internal package names like
>> Eclipse does. This would not stop me from hacking my way in there but
>> at least I should not be surprised if a minor version breaks internal
>> binary compat.
>
> +1
>
> But it's not always obvious initially which classes are which.
>
> [Also of course one should start by making everything private
> (especially mutable fields) and only increasing visibility as needed.]
>
>> Gary
>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by sebb <se...@gmail.com>.
On 8 October 2013 17:36, Gary Gregory <ga...@gmail.com> wrote:
> On Oct 8, 2013, at 10:09, James Carman <ja...@carmanconsulting.com> wrote:
>
>> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>>>
>>> That's not the issue. We want to avoid unresolvable incompatibilities in
>>> transitive dependencies. Our components are used by many projects, an
>>> incompatibility could render impossible the use of two components
>>> together, and you are stuck until the components are updated to use the
>>> same version of the common dependency.
>>>
>>> ASM and BouncyCastle are two examples of widely used projects that don't
>>> care at all about the compatibilities, and this is causing pain and
>>> wasting time to a lot of smart people.
>>
>> I think you misunderstand my intent. We have left out features before
>> (ones that folks blogged about and said they liked) because a user
>> could do something stupid with it.
>>
>> What you're talking about is "jar hell" and we have already addressed
>> that with our naming convention for major release bumps (changing
>> artifactId and package name). I'm cool with that idea and I think
>> it's a pretty good approach. I don't see anyone else doing it, which
>> is interesting.
>>
>
> Yep, our approach works. You cannot be kind of binary compatible, it's
> all or nothing.
Yes and no.
Yes, one can say unambiguously that a particular change is - or is not
- binary compatible according to the Java compatibility rules.
But it may still be OK to break binary compatibility without package
renames if the likelihood of it affecting end users is extremely low.
I think the way to approach binary incompatibility is as follows:
- check whether it's really necessary to break compatibility;
sometimes it happens by accident and can be fixed
- if the break really is necessary, evaluate how likely it is to
affect 3rd party code.
Depending on the severity of the break, it may be necessary to change
package name/Maven coordinates, or it may just require a warning in
the release notes.
It's not always easy to get this right, which is where it's useful to
have a community of experienced developers.
> I do like the idea of internal package names like
> Eclipse does. This would not stop me from hacking my way in there but
> at least I should not be surprised if a minor version breaks internal
> binary compat.
+1
But it's not always obvious initially which classes are which.
[Also of course one should start by making everything private
(especially mutable fields) and only increasing visibility as needed.]
> Gary
>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Gary Gregory <ga...@gmail.com>.
On Oct 8, 2013, at 10:09, James Carman <ja...@carmanconsulting.com> wrote:
> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>>
>> That's not the issue. We want to avoid unresolvable incompatibilities in
>> transitive dependencies. Our components are used by many projects, an
>> incompatibility could render impossible the use of two components
>> together, and you are stuck until the components are updated to use the
>> same version of the common dependency.
>>
>> ASM and BouncyCastle are two examples of widely used projects that don't
>> care at all about the compatibilities, and this is causing pain and
>> wasting time to a lot of smart people.
>
> I think you misunderstand my intent. We have left out features before
> (ones that folks blogged about and said they liked) because a user
> could do something stupid with it.
>
> What you're talking about is "jar hell" and we have already addressed
> that with our naming convention for major release bumps (changing
> artifactId and package name). I'm cool with that idea and I think
> it's a pretty good approach. I don't see anyone else doing it, which
> is interesting.
>
Yep, our approach works. You cannot be kind of binary compatible, it's
all or nothing. I do like the idea of internal package names like
Eclipse does. This would not stop me from hacking my way in there but
at least I should not be surprised if a minor version breaks internal
binary compat.
Gary
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Gary Gregory <ga...@gmail.com>.
The only relaxing I could see is for code in internal packages.
Gary
On Oct 8, 2013, at 12:28, James Carman <ja...@carmanconsulting.com> wrote:
> Okay, so what I'm hearing is that we want to relax our "no API breaks
> within a major release" policy. Also, it sounds like we need to come
> up with the naming convention where we can rope off parts of our API
> as implementation details and they're not to be relied upon by outside
> parties (they may do so at their own peril).
>
> On Tue, Oct 8, 2013 at 12:22 PM, Phil Steitz <ph...@gmail.com> wrote:
>>
>>
>>> On Oct 8, 2013, at 7:08 AM, James Carman <ja...@carmanconsulting.com> wrote:
>>>
>>>> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>>>>
>>>> That's not the issue. We want to avoid unresolvable incompatibilities in
>>>> transitive dependencies. Our components are used by many projects, an
>>>> incompatibility could render impossible the use of two components
>>>> together, and you are stuck until the components are updated to use the
>>>> same version of the common dependency.
>>>>
>>>> ASM and BouncyCastle are two examples of widely used projects that don't
>>>> care at all about the compatibilities, and this is causing pain and
>>>> wasting time to a lot of smart people.
>>>
>>> I think you misunderstand my intent. We have left out features before
>>> (ones that folks blogged about and said they liked) because a user
>>> could do something stupid with it.
>>>
>>> What you're talking about is "jar hell" and we have already addressed
>>> that with our naming convention for major release bumps (changing
>>> artifactId and package name). I'm cool with that idea and I think
>>> it's a pretty good approach. I don't see anyone else doing it, which
>>> is interesting.
>> I agree that the policy we have now to change package names is reasonable, but it has two drawbacks, one for us and one for users. For us, it forces us to branch and cut a new major release each time we want/need to release something with a compat break. For users, it forces them to redo all of their imports and swallow whatever other refactoring we have thrown in to the major release. I think it makes sense to relax a bit and allow
>>
>> 0) some kind of annotation or naming scheme that allows us to mark classes as "internal"
>> 1) a way to judge some compat breaks even outside the stuff in 0) as "minor" and allow them between major releases.
>>
>> In theory Gump and downstream packaging tools could be used to verify 1), as well as lots of notification / time for comment. I am not sure fixed rules could be defined for it though. We have actually done it a couple of times in [math] and never had anyone scream (though there have been some complaints about API stability in general - which would somewhat ironically likely be improved if we allowed ourselves a little leeway in 0) and 1))
>>
>> Phil
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by James Carman <ja...@carmanconsulting.com>.
Okay, so what I'm hearing is that we want to relax our "no API breaks
within a major release" policy. Also, it sounds like we need to come
up with the naming convention where we can rope off parts of our API
as implementation details and they're not to be relied upon by outside
parties (they may do so at their own peril).
On Tue, Oct 8, 2013 at 12:22 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>
>> On Oct 8, 2013, at 7:08 AM, James Carman <ja...@carmanconsulting.com> wrote:
>>
>>> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>>>
>>> That's not the issue. We want to avoid unresolvable incompatibilities in
>>> transitive dependencies. Our components are used by many projects, an
>>> incompatibility could render impossible the use of two components
>>> together, and you are stuck until the components are updated to use the
>>> same version of the common dependency.
>>>
>>> ASM and BouncyCastle are two examples of widely used projects that don't
>>> care at all about the compatibilities, and this is causing pain and
>>> wasting time to a lot of smart people.
>>
>> I think you misunderstand my intent. We have left out features before
>> (ones that folks blogged about and said they liked) because a user
>> could do something stupid with it.
>>
>> What you're talking about is "jar hell" and we have already addressed
>> that with our naming convention for major release bumps (changing
>> artifactId and package name). I'm cool with that idea and I think
>> it's a pretty good approach. I don't see anyone else doing it, which
>> is interesting.
>>
> I agree that the policy we have now to change package names is reasonable, but it has two drawbacks, one for us and one for users. For us, it forces us to branch and cut a new major release each time we want/need to release something with a compat break. For users, it forces them to redo all of their imports and swallow whatever other refactoring we have thrown in to the major release. I think it makes sense to relax a bit and allow
>
> 0) some kind of annotation or naming scheme that allows us to mark classes as "internal"
> 1) a way to judge some compat breaks even outside the stuff in 0) as "minor" and allow them between major releases.
>
> In theory Gump and downstream packaging tools could be used to verify 1), as well as lots of notification / time for comment. I am not sure fixed rules could be defined for it though. We have actually done it a couple of times in [math] and never had anyone scream (though there have been some complaints about API stability in general - which would somewhat ironically likely be improved if we allowed ourselves a little leeway in 0) and 1))
>
> Phil
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Phil Steitz <ph...@gmail.com>.
> On Oct 8, 2013, at 7:08 AM, James Carman <ja...@carmanconsulting.com> wrote:
>
>> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>>
>> That's not the issue. We want to avoid unresolvable incompatibilities in
>> transitive dependencies. Our components are used by many projects, an
>> incompatibility could render impossible the use of two components
>> together, and you are stuck until the components are updated to use the
>> same version of the common dependency.
>>
>> ASM and BouncyCastle are two examples of widely used projects that don't
>> care at all about the compatibilities, and this is causing pain and
>> wasting time to a lot of smart people.
>
> I think you misunderstand my intent. We have left out features before
> (ones that folks blogged about and said they liked) because a user
> could do something stupid with it.
>
> What you're talking about is "jar hell" and we have already addressed
> that with our naming convention for major release bumps (changing
> artifactId and package name). I'm cool with that idea and I think
> it's a pretty good approach. I don't see anyone else doing it, which
> is interesting.
>
I agree that the policy we have now to change package names is reasonable, but it has two drawbacks, one for us and one for users. For us, it forces us to branch and cut a new major release each time we want/need to release something with a compat break. For users, it forces them to redo all of their imports and swallow whatever other refactoring we have thrown in to the major release. I think it makes sense to relax a bit and allow
0) some kind of annotation or naming scheme that allows us to mark classes as "internal"
1) a way to judge some compat breaks even outside the stuff in 0) as "minor" and allow them between major releases.
In theory Gump and downstream packaging tools could be used to verify 1), as well as lots of notification / time for comment. I am not sure fixed rules could be defined for it though. We have actually done it a couple of times in [math] and never had anyone scream (though there have been some complaints about API stability in general - which would somewhat ironically likely be improved if we allowed ourselves a little leeway in 0) and 1))
Phil
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by James Carman <ja...@carmanconsulting.com>.
On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>
> That's not the issue. We want to avoid unresolvable incompatibilities in
> transitive dependencies. Our components are used by many projects, an
> incompatibility could render impossible the use of two components
> together, and you are stuck until the components are updated to use the
> same version of the common dependency.
>
> ASM and BouncyCastle are two examples of widely used projects that don't
> care at all about the compatibilities, and this is causing pain and
> wasting time to a lot of smart people.
>
I think you misunderstand my intent. We have left out features before
(ones that folks blogged about and said they liked) because a user
could do something stupid with it.
What you're talking about is "jar hell" and we have already addressed
that with our naming convention for major release bumps (changing
artifactId and package name). I'm cool with that idea and I think
it's a pretty good approach. I don't see anyone else doing it, which
is interesting.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 08/10/2013 15:46, James Carman a écrit :
> Another concept I'd like to bring up is the fascination we seem to
> have with protecting the users from being blithering idiots.
That's not the issue. We want to avoid unresolvable incompatibilities in
transitive dependencies. Our components are used by many projects, an
incompatibility could render impossible the use of two components
together, and you are stuck until the components are updated to use the
same version of the common dependency.
ASM and BouncyCastle are two examples of widely used projects that don't
care at all about the compatibilities, and this is causing pain and
wasting time to a lot of smart people.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by James Carman <ja...@carmanconsulting.com>.
Another concept I'd like to bring up is the fascination we seem to
have with protecting the users from being blithering idiots. We
cannot protect them from themselves completely. At some point, we
have to give them the benefit of the doubt that they're not complete
morons. If they do indeed do something as stupid as relying upon type
inference in a case where it's clearly not applicable, then so be it.
They'll get a ClassCastException and figure it out in short order.
On Tue, Oct 8, 2013 at 4:55 AM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>
>> - loosen API compatibility policy?
>
> This topic alone deserves its own thread I think.
>
> Ensuring binary/source compatibility is very important. This is an area
> where Guava is clearly not a good example, they deprecate and remove
> stuff frequently. Every time I update the Debian package for Guava I
> know this will break reverse dependencies, I have to fix it and convince
> the upstream projects to upgrade as well. On the other hand updating a
> Commons component is just a breeze.
>
> That being said, I think we are too strict on the compatibility rules.
> Some incompatible changes are much less risky than others. For example,
> adding a new method in an interface released less than 6 months ago
> shouldn't be vetoed, but renaming public methods in a code that has been
> in the wild for years shouldn't happen.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by James Carman <ja...@carmanconsulting.com>.
That's kind of a mellow song from DMX. He's not yelling as much as usual.
On Tue, Oct 8, 2013 at 8:53 AM, Torsten Curdt <tc...@vafer.org> wrote:
> http://www.youtube.com/watch?v=MqitYkILvnQ&feature=player_detailpage#t=63
>
> Gary, really no offense - but I just could not resist :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Torsten Curdt <tc...@vafer.org>.
http://www.youtube.com/watch?v=MqitYkILvnQ&feature=player_detailpage#t=63
Gary, really no offense - but I just could not resist :)
Re: [DISCUSS] API compatibility policy
Posted by James Carman <ja...@carmanconsulting.com>.
The goal is to level set, so that we don't run into this stuff.
On Tue, Oct 8, 2013 at 9:27 AM, Phil Steitz <ph...@gmail.com> wrote:
>
>
>> On Oct 8, 2013, at 5:52 AM, James Carman <ja...@carmanconsulting.com> wrote:
>>
>> However, code modifications can be vetoed and nobody can overrule the veto.
>>
> Honestly, I have not seen that much, other Sw What we need IMO is less talk and more code. Nobody has "blocked" or "vetoed" any new work on major release versions. What has been lacking is critical mass to really collaborate on the new stuff and fix bugs in the stuff that has been released. There are infinitely many natural numbers to work with. Just change package name, start a branch and go. We should all realize of course that if our APIs are too unstable and we don't back port bug fixes because all we want to do is "innovate" people won't really use our stuff.
>
>>> On Tue, Oct 8, 2013 at 8:49 AM, Gary Gregory <ga...@gmail.com> wrote:
>>> On Tue, Oct 8, 2013 at 8:38 AM, James Carman <ja...@carmanconsulting.com>wrote:
>>>
>>>> Yes, we know we're allowed to do that, but folks seem to fight against
>>>> moving forward.
>>>
>>> All you need is a [VOTE] and be done with it.
>>>
>>> Gary
>>>
>>>
>>>>
>>>> On Tue, Oct 8, 2013 at 8:35 AM, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>> You can break BC all you want when you do it in a NEW package. For
>>>>> example lang3.
>>>>>
>>>>> Gary
>>>>>
>>>>>> On Oct 8, 2013, at 6:41, Torsten Curdt <tc...@vafer.org> wrote:
>>>>>>
>>>>>> Cannot remember which component from the top of my head - but it was
>>>>>> related to package name changes.
>>>>>>
>>>>>> My style of thinking: x.y.z
>>>>>>
>>>>>> x - no compatibility
>>>>>> y - source compatibility
>>>>>> z - binary compatibility
>>>>>>
>>>>>> is simple and makes sense.
>>>>>>
>>>>>> It's OK to put some burden on the users when upgrading - as long as the
>>>>>> expectations are set correctly.
>>>>>> But I am pretty sure we discussed that before and some people did not
>>>> agree.
>>>>>>
>>>>>> cheers,
>>>>>> Torsten
>>>>>>
>>>>>>
>>>>>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org>
>>>> wrote:
>>>>>>
>>>>>>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>>>>>>
>>>>>>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>>>>>>
>>>>>>>>> - loosen API compatibility policy?
>>>>>>>
>>>>>>>> This topic alone deserves its own thread I think.
>>>>>>>
>>>>>>>> Ensuring binary/source compatibility is very important.
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> I guess I've done too much ruby with "every bundle update runs the risk
>>>>>>> of breaking everything" lately. I really value the stability commons
>>>>>>> provides.
>>>>>>>
>>>>>>> That being said, I'm sure there are cases where our policy seems
>>>>>>> stricter than it needs to be - even though I haven't seen a really
>>>>>>> difficult case in the one component I contribute to.
>>>>>>>
>>>>>>> Stefan
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Stefan Bodewig <bo...@apache.org>.
+1
Stefan
On 2013-10-08, James Carman wrote:
> Agreed. I think we should come up with a naming convention. The OSGi
> community (the maven bundle plugin) has adopted the notion that any
> package named "impl" or "internal" will not be exported. Perhaps we
> set up that expectation to our users, too. If it's in a package named
> as such, then it can change. Use at your own risk!
> On Tue, Oct 8, 2013 at 9:35 AM, Phil Steitz <ph...@gmail.com> wrote:
>> Sorry, got away from me before I finished. By "other Sw" I meant "other than when someone wants to slip in a comparability break outside a major release." I agree with Luc that we should allow ourselves to designate parts of the API as "internal" so subject to change between major releases. For [math] at least that would be a big help.
>> Sorry for the fat-fingering (again)
>>> On Oct 8, 2013, at 6:27 AM, Phil Steitz <ph...@gmail.com> wrote:
>>>> On Oct 8, 2013, at 5:52 AM, James Carman <ja...@carmanconsulting.com> wrote:
>>>> However, code modifications can be vetoed and nobody can overrule the veto.
>>> Honestly, I have not seen that much, other Sw What we need IMO is less talk and more code. Nobody has "blocked" or "vetoed" any new work on major release versions. What has been lacking is critical mass to really collaborate on the new stuff and fix bugs in the stuff that has been released. There are infinitely many natural numbers to work with. Just change package name, start a branch and go. We should all realize of course that if our APIs are too unstable and we don't back port bug fixes because all we want to do is "innovate" people won't really use our stuff.
>>>>> On Tue, Oct 8, 2013 at 8:49 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>> On Tue, Oct 8, 2013 at 8:38 AM, James Carman <ja...@carmanconsulting.com>wrote:
>>>>>> Yes, we know we're allowed to do that, but folks seem to fight against
>>>>>> moving forward.
>>>>> All you need is a [VOTE] and be done with it.
>>>>> Gary
>>>>>> On Tue, Oct 8, 2013 at 8:35 AM, Gary Gregory <ga...@gmail.com>
>>>>>> wrote:
>>>>>>> You can break BC all you want when you do it in a NEW package. For
>>>>>>> example lang3.
>>>>>>> Gary
>>>>>>>> On Oct 8, 2013, at 6:41, Torsten Curdt <tc...@vafer.org> wrote:
>>>>>>>> Cannot remember which component from the top of my head - but it was
>>>>>>>> related to package name changes.
>>>>>>>> My style of thinking: x.y.z
>>>>>>>> x - no compatibility
>>>>>>>> y - source compatibility
>>>>>>>> z - binary compatibility
>>>>>>>> is simple and makes sense.
>>>>>>>> It's OK to put some burden on the users when upgrading - as long as the
>>>>>>>> expectations are set correctly.
>>>>>>>> But I am pretty sure we discussed that before and some people did not
>>>>>> agree.
>>>>>>>> cheers,
>>>>>>>> Torsten
>>>>>>>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org>
>>>>>> wrote:
>>>>>>>>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>>>>>>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>>>>>>>>>> - loosen API compatibility policy?
>>>>>>>>>> This topic alone deserves its own thread I think.
>>>>>>>>>> Ensuring binary/source compatibility is very important.
>>>>>>>>>> 1
>>>>>>>>> I guess I've done too much ruby with "every bundle update runs the risk
>>>>>>>>> of breaking everything" lately. I really value the stability commons
>>>>>>>>> provides.
>>>>>>>>> That being said, I'm sure there are cases where our policy seems
>>>>>>>>> stricter than it needs to be - even though I haven't seen a really
>>>>>>>>> difficult case in the one component I contribute to.
>>>>>>>>> Stefan
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by James Carman <ja...@carmanconsulting.com>.
Agreed. I think we should come up with a naming convention. The OSGi
community (the maven bundle plugin) has adopted the notion that any
package named "impl" or "internal" will not be exported. Perhaps we
set up that expectation to our users, too. If it's in a package named
as such, then it can change. Use at your own risk!
On Tue, Oct 8, 2013 at 9:35 AM, Phil Steitz <ph...@gmail.com> wrote:
> Sorry, got away from me before I finished. By "other Sw" I meant "other than when someone wants to slip in a comparability break outside a major release." I agree with Luc that we should allow ourselves to designate parts of the API as "internal" so subject to change between major releases. For [math] at least that would be a big help.
>
> Sorry for the fat-fingering (again)
>
>> On Oct 8, 2013, at 6:27 AM, Phil Steitz <ph...@gmail.com> wrote:
>>
>>
>>
>>> On Oct 8, 2013, at 5:52 AM, James Carman <ja...@carmanconsulting.com> wrote:
>>>
>>> However, code modifications can be vetoed and nobody can overrule the veto.
>> Honestly, I have not seen that much, other Sw What we need IMO is less talk and more code. Nobody has "blocked" or "vetoed" any new work on major release versions. What has been lacking is critical mass to really collaborate on the new stuff and fix bugs in the stuff that has been released. There are infinitely many natural numbers to work with. Just change package name, start a branch and go. We should all realize of course that if our APIs are too unstable and we don't back port bug fixes because all we want to do is "innovate" people won't really use our stuff.
>>
>>>> On Tue, Oct 8, 2013 at 8:49 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>> On Tue, Oct 8, 2013 at 8:38 AM, James Carman <ja...@carmanconsulting.com>wrote:
>>>>
>>>>> Yes, we know we're allowed to do that, but folks seem to fight against
>>>>> moving forward.
>>>>
>>>> All you need is a [VOTE] and be done with it.
>>>>
>>>> Gary
>>>>
>>>>
>>>>>
>>>>> On Tue, Oct 8, 2013 at 8:35 AM, Gary Gregory <ga...@gmail.com>
>>>>> wrote:
>>>>>> You can break BC all you want when you do it in a NEW package. For
>>>>>> example lang3.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>>> On Oct 8, 2013, at 6:41, Torsten Curdt <tc...@vafer.org> wrote:
>>>>>>>
>>>>>>> Cannot remember which component from the top of my head - but it was
>>>>>>> related to package name changes.
>>>>>>>
>>>>>>> My style of thinking: x.y.z
>>>>>>>
>>>>>>> x - no compatibility
>>>>>>> y - source compatibility
>>>>>>> z - binary compatibility
>>>>>>>
>>>>>>> is simple and makes sense.
>>>>>>>
>>>>>>> It's OK to put some burden on the users when upgrading - as long as the
>>>>>>> expectations are set correctly.
>>>>>>> But I am pretty sure we discussed that before and some people did not
>>>>> agree.
>>>>>>>
>>>>>>> cheers,
>>>>>>> Torsten
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org>
>>>>> wrote:
>>>>>>>
>>>>>>>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>>>>>>>
>>>>>>>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>>>>>>>
>>>>>>>>>> - loosen API compatibility policy?
>>>>>>>>
>>>>>>>>> This topic alone deserves its own thread I think.
>>>>>>>>
>>>>>>>>> Ensuring binary/source compatibility is very important.
>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> I guess I've done too much ruby with "every bundle update runs the risk
>>>>>>>> of breaking everything" lately. I really value the stability commons
>>>>>>>> provides.
>>>>>>>>
>>>>>>>> That being said, I'm sure there are cases where our policy seems
>>>>>>>> stricter than it needs to be - even though I haven't seen a really
>>>>>>>> difficult case in the one component I contribute to.
>>>>>>>>
>>>>>>>> Stefan
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Phil Steitz <ph...@gmail.com>.
Sorry, got away from me before I finished. By "other Sw" I meant "other than when someone wants to slip in a comparability break outside a major release." I agree with Luc that we should allow ourselves to designate parts of the API as "internal" so subject to change between major releases. For [math] at least that would be a big help.
Sorry for the fat-fingering (again)
> On Oct 8, 2013, at 6:27 AM, Phil Steitz <ph...@gmail.com> wrote:
>
>
>
>> On Oct 8, 2013, at 5:52 AM, James Carman <ja...@carmanconsulting.com> wrote:
>>
>> However, code modifications can be vetoed and nobody can overrule the veto.
> Honestly, I have not seen that much, other Sw What we need IMO is less talk and more code. Nobody has "blocked" or "vetoed" any new work on major release versions. What has been lacking is critical mass to really collaborate on the new stuff and fix bugs in the stuff that has been released. There are infinitely many natural numbers to work with. Just change package name, start a branch and go. We should all realize of course that if our APIs are too unstable and we don't back port bug fixes because all we want to do is "innovate" people won't really use our stuff.
>
>>> On Tue, Oct 8, 2013 at 8:49 AM, Gary Gregory <ga...@gmail.com> wrote:
>>> On Tue, Oct 8, 2013 at 8:38 AM, James Carman <ja...@carmanconsulting.com>wrote:
>>>
>>>> Yes, we know we're allowed to do that, but folks seem to fight against
>>>> moving forward.
>>>
>>> All you need is a [VOTE] and be done with it.
>>>
>>> Gary
>>>
>>>
>>>>
>>>> On Tue, Oct 8, 2013 at 8:35 AM, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>> You can break BC all you want when you do it in a NEW package. For
>>>>> example lang3.
>>>>>
>>>>> Gary
>>>>>
>>>>>> On Oct 8, 2013, at 6:41, Torsten Curdt <tc...@vafer.org> wrote:
>>>>>>
>>>>>> Cannot remember which component from the top of my head - but it was
>>>>>> related to package name changes.
>>>>>>
>>>>>> My style of thinking: x.y.z
>>>>>>
>>>>>> x - no compatibility
>>>>>> y - source compatibility
>>>>>> z - binary compatibility
>>>>>>
>>>>>> is simple and makes sense.
>>>>>>
>>>>>> It's OK to put some burden on the users when upgrading - as long as the
>>>>>> expectations are set correctly.
>>>>>> But I am pretty sure we discussed that before and some people did not
>>>> agree.
>>>>>>
>>>>>> cheers,
>>>>>> Torsten
>>>>>>
>>>>>>
>>>>>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org>
>>>> wrote:
>>>>>>
>>>>>>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>>>>>>
>>>>>>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>>>>>>
>>>>>>>>> - loosen API compatibility policy?
>>>>>>>
>>>>>>>> This topic alone deserves its own thread I think.
>>>>>>>
>>>>>>>> Ensuring binary/source compatibility is very important.
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> I guess I've done too much ruby with "every bundle update runs the risk
>>>>>>> of breaking everything" lately. I really value the stability commons
>>>>>>> provides.
>>>>>>>
>>>>>>> That being said, I'm sure there are cases where our policy seems
>>>>>>> stricter than it needs to be - even though I haven't seen a really
>>>>>>> difficult case in the one component I contribute to.
>>>>>>>
>>>>>>> Stefan
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Phil Steitz <ph...@gmail.com>.
> On Oct 8, 2013, at 5:52 AM, James Carman <ja...@carmanconsulting.com> wrote:
>
> However, code modifications can be vetoed and nobody can overrule the veto.
>
Honestly, I have not seen that much, other Sw What we need IMO is less talk and more code. Nobody has "blocked" or "vetoed" any new work on major release versions. What has been lacking is critical mass to really collaborate on the new stuff and fix bugs in the stuff that has been released. There are infinitely many natural numbers to work with. Just change package name, start a branch and go. We should all realize of course that if our APIs are too unstable and we don't back port bug fixes because all we want to do is "innovate" people won't really use our stuff.
>> On Tue, Oct 8, 2013 at 8:49 AM, Gary Gregory <ga...@gmail.com> wrote:
>> On Tue, Oct 8, 2013 at 8:38 AM, James Carman <ja...@carmanconsulting.com>wrote:
>>
>>> Yes, we know we're allowed to do that, but folks seem to fight against
>>> moving forward.
>>
>> All you need is a [VOTE] and be done with it.
>>
>> Gary
>>
>>
>>>
>>> On Tue, Oct 8, 2013 at 8:35 AM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>> You can break BC all you want when you do it in a NEW package. For
>>>> example lang3.
>>>>
>>>> Gary
>>>>
>>>>> On Oct 8, 2013, at 6:41, Torsten Curdt <tc...@vafer.org> wrote:
>>>>>
>>>>> Cannot remember which component from the top of my head - but it was
>>>>> related to package name changes.
>>>>>
>>>>> My style of thinking: x.y.z
>>>>>
>>>>> x - no compatibility
>>>>> y - source compatibility
>>>>> z - binary compatibility
>>>>>
>>>>> is simple and makes sense.
>>>>>
>>>>> It's OK to put some burden on the users when upgrading - as long as the
>>>>> expectations are set correctly.
>>>>> But I am pretty sure we discussed that before and some people did not
>>> agree.
>>>>>
>>>>> cheers,
>>>>> Torsten
>>>>>
>>>>>
>>>>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org>
>>> wrote:
>>>>>
>>>>>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>>>>>
>>>>>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>>>>>
>>>>>>>> - loosen API compatibility policy?
>>>>>>
>>>>>>> This topic alone deserves its own thread I think.
>>>>>>
>>>>>>> Ensuring binary/source compatibility is very important.
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> I guess I've done too much ruby with "every bundle update runs the risk
>>>>>> of breaking everything" lately. I really value the stability commons
>>>>>> provides.
>>>>>>
>>>>>> That being said, I'm sure there are cases where our policy seems
>>>>>> stricter than it needs to be - even though I haven't seen a really
>>>>>> difficult case in the one component I contribute to.
>>>>>>
>>>>>> Stefan
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by James Carman <ja...@carmanconsulting.com>.
However, code modifications can be vetoed and nobody can overrule the veto.
On Tue, Oct 8, 2013 at 8:49 AM, Gary Gregory <ga...@gmail.com> wrote:
> On Tue, Oct 8, 2013 at 8:38 AM, James Carman <ja...@carmanconsulting.com>wrote:
>
>> Yes, we know we're allowed to do that, but folks seem to fight against
>> moving forward.
>>
>
> All you need is a [VOTE] and be done with it.
>
> Gary
>
>
>>
>> On Tue, Oct 8, 2013 at 8:35 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>> > You can break BC all you want when you do it in a NEW package. For
>> > example lang3.
>> >
>> > Gary
>> >
>> > On Oct 8, 2013, at 6:41, Torsten Curdt <tc...@vafer.org> wrote:
>> >
>> >> Cannot remember which component from the top of my head - but it was
>> >> related to package name changes.
>> >>
>> >> My style of thinking: x.y.z
>> >>
>> >> x - no compatibility
>> >> y - source compatibility
>> >> z - binary compatibility
>> >>
>> >> is simple and makes sense.
>> >>
>> >> It's OK to put some burden on the users when upgrading - as long as the
>> >> expectations are set correctly.
>> >> But I am pretty sure we discussed that before and some people did not
>> agree.
>> >>
>> >> cheers,
>> >> Torsten
>> >>
>> >>
>> >> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org>
>> wrote:
>> >>
>> >>> On 2013-10-08, Emmanuel Bourg wrote:
>> >>>
>> >>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>> >>>
>> >>>>> - loosen API compatibility policy?
>> >>>
>> >>>> This topic alone deserves its own thread I think.
>> >>>
>> >>>> Ensuring binary/source compatibility is very important.
>> >>>
>> >>> +1
>> >>>
>> >>> I guess I've done too much ruby with "every bundle update runs the risk
>> >>> of breaking everything" lately. I really value the stability commons
>> >>> provides.
>> >>>
>> >>> That being said, I'm sure there are cases where our policy seems
>> >>> stricter than it needs to be - even though I haven't seen a really
>> >>> difficult case in the one component I contribute to.
>> >>>
>> >>> Stefan
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>
>> >>>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Oct 8, 2013 at 8:38 AM, James Carman <ja...@carmanconsulting.com>wrote:
> Yes, we know we're allowed to do that, but folks seem to fight against
> moving forward.
>
All you need is a [VOTE] and be done with it.
Gary
>
> On Tue, Oct 8, 2013 at 8:35 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> > You can break BC all you want when you do it in a NEW package. For
> > example lang3.
> >
> > Gary
> >
> > On Oct 8, 2013, at 6:41, Torsten Curdt <tc...@vafer.org> wrote:
> >
> >> Cannot remember which component from the top of my head - but it was
> >> related to package name changes.
> >>
> >> My style of thinking: x.y.z
> >>
> >> x - no compatibility
> >> y - source compatibility
> >> z - binary compatibility
> >>
> >> is simple and makes sense.
> >>
> >> It's OK to put some burden on the users when upgrading - as long as the
> >> expectations are set correctly.
> >> But I am pretty sure we discussed that before and some people did not
> agree.
> >>
> >> cheers,
> >> Torsten
> >>
> >>
> >> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org>
> wrote:
> >>
> >>> On 2013-10-08, Emmanuel Bourg wrote:
> >>>
> >>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
> >>>
> >>>>> - loosen API compatibility policy?
> >>>
> >>>> This topic alone deserves its own thread I think.
> >>>
> >>>> Ensuring binary/source compatibility is very important.
> >>>
> >>> +1
> >>>
> >>> I guess I've done too much ruby with "every bundle update runs the risk
> >>> of breaking everything" lately. I really value the stability commons
> >>> provides.
> >>>
> >>> That being said, I'm sure there are cases where our policy seems
> >>> stricter than it needs to be - even though I haven't seen a really
> >>> difficult case in the one component I contribute to.
> >>>
> >>> Stefan
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [DISCUSS] API compatibility policy
Posted by James Carman <ja...@carmanconsulting.com>.
Yes, we know we're allowed to do that, but folks seem to fight against
moving forward.
On Tue, Oct 8, 2013 at 8:35 AM, Gary Gregory <ga...@gmail.com> wrote:
> You can break BC all you want when you do it in a NEW package. For
> example lang3.
>
> Gary
>
> On Oct 8, 2013, at 6:41, Torsten Curdt <tc...@vafer.org> wrote:
>
>> Cannot remember which component from the top of my head - but it was
>> related to package name changes.
>>
>> My style of thinking: x.y.z
>>
>> x - no compatibility
>> y - source compatibility
>> z - binary compatibility
>>
>> is simple and makes sense.
>>
>> It's OK to put some burden on the users when upgrading - as long as the
>> expectations are set correctly.
>> But I am pretty sure we discussed that before and some people did not agree.
>>
>> cheers,
>> Torsten
>>
>>
>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org> wrote:
>>
>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>
>>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>>
>>>>> - loosen API compatibility policy?
>>>
>>>> This topic alone deserves its own thread I think.
>>>
>>>> Ensuring binary/source compatibility is very important.
>>>
>>> +1
>>>
>>> I guess I've done too much ruby with "every bundle update runs the risk
>>> of breaking everything" lately. I really value the stability commons
>>> provides.
>>>
>>> That being said, I'm sure there are cases where our policy seems
>>> stricter than it needs to be - even though I haven't seen a really
>>> difficult case in the one component I contribute to.
>>>
>>> Stefan
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Gary Gregory <ga...@gmail.com>.
You can break BC all you want when you do it in a NEW package. For
example lang3.
Gary
On Oct 8, 2013, at 6:41, Torsten Curdt <tc...@vafer.org> wrote:
> Cannot remember which component from the top of my head - but it was
> related to package name changes.
>
> My style of thinking: x.y.z
>
> x - no compatibility
> y - source compatibility
> z - binary compatibility
>
> is simple and makes sense.
>
> It's OK to put some burden on the users when upgrading - as long as the
> expectations are set correctly.
> But I am pretty sure we discussed that before and some people did not agree.
>
> cheers,
> Torsten
>
>
> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org> wrote:
>
>> On 2013-10-08, Emmanuel Bourg wrote:
>>
>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>
>>>> - loosen API compatibility policy?
>>
>>> This topic alone deserves its own thread I think.
>>
>>> Ensuring binary/source compatibility is very important.
>>
>> +1
>>
>> I guess I've done too much ruby with "every bundle update runs the risk
>> of breaking everything" lately. I really value the stability commons
>> provides.
>>
>> That being said, I'm sure there are cases where our policy seems
>> stricter than it needs to be - even though I haven't seen a really
>> difficult case in the one component I contribute to.
>>
>> Stefan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Paul Benedict <pb...@apache.org>.
A good resource if you didn't know it existed:
http://commons.apache.org/releases/versioning.html
On Tue, Oct 8, 2013 at 3:54 PM, Gary Gregory <ga...@gmail.com> wrote:
> On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl
> <si...@it20one.at> wrote:
> > That's a reasonable style of versioning :)
> >
> > I had many issues with binary compatibilty with a commons-email release
> due to changing the return value from void to a this reference plus some
> moving of constants. You basically end up with either many restrictions or
> creating major releases
>
> Then just create major releases! ;) Why would you not want to provide
> BC? Why add to the jar hell problem? I, the developer, have no control
> over how the API I provide will be used and distributed...
>
> G
>
> >
> > Cheers,
> >
> > Siegfried Goeschl
> >
> >> Am 08.10.2013 um 12:40 schrieb Torsten Curdt <tc...@vafer.org>:
> >>
> >> Cannot remember which component from the top of my head - but it was
> >> related to package name changes.
> >>
> >> My style of thinking: x.y.z
> >>
> >> x - no compatibility
> >> y - source compatibility
> >> z - binary compatibility
> >>
> >> is simple and makes sense.
> >>
> >> It's OK to put some burden on the users when upgrading - as long as the
> >> expectations are set correctly.
> >> But I am pretty sure we discussed that before and some people did not
> agree.
> >>
> >> cheers,
> >> Torsten
> >>
> >>
> >>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org>
> wrote:
> >>>
> >>>> On 2013-10-08, Emmanuel Bourg wrote:
> >>>>
> >>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
> >>>
> >>>>> - loosen API compatibility policy?
> >>>
> >>>> This topic alone deserves its own thread I think.
> >>>
> >>>> Ensuring binary/source compatibility is very important.
> >>>
> >>> +1
> >>>
> >>> I guess I've done too much ruby with "every bundle update runs the risk
> >>> of breaking everything" lately. I really value the stability commons
> >>> provides.
> >>>
> >>> That being said, I'm sure there are cases where our policy seems
> >>> stricter than it needs to be - even though I haven't seen a really
> >>> difficult case in the one component I contribute to.
> >>>
> >>> Stefan
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Cheers,
Paul
Re: [DISCUSS] API compatibility policy
Posted by sebb <se...@gmail.com>.
On 9 October 2013 05:14, Siegfried Goeschl <si...@it20one.at> wrote:
> Hi Gary,
>
> A new major release requires a new package name, site, build and so on - think of commons-lang v1,2,3
Huh?
A major release does not imply an API break, though the reverse is true.
> Cheers,
>
> Siegfried Goeschl
>
>> Am 08.10.2013 um 22:54 schrieb Gary Gregory <ga...@gmail.com>:
>>
>> On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl
>> <si...@it20one.at> wrote:
>>> That's a reasonable style of versioning :)
>>>
>>> I had many issues with binary compatibilty with a commons-email release due to changing the return value from void to a this reference plus some moving of constants. You basically end up with either many restrictions or creating major releases
>>
>> Then just create major releases! ;) Why would you not want to provide
>> BC? Why add to the jar hell problem? I, the developer, have no control
>> over how the API I provide will be used and distributed...
>>
>> G
>>
>>>
>>> Cheers,
>>>
>>> Siegfried Goeschl
>>>
>>>> Am 08.10.2013 um 12:40 schrieb Torsten Curdt <tc...@vafer.org>:
>>>>
>>>> Cannot remember which component from the top of my head - but it was
>>>> related to package name changes.
>>>>
>>>> My style of thinking: x.y.z
>>>>
>>>> x - no compatibility
>>>> y - source compatibility
>>>> z - binary compatibility
>>>>
>>>> is simple and makes sense.
>>>>
>>>> It's OK to put some burden on the users when upgrading - as long as the
>>>> expectations are set correctly.
>>>> But I am pretty sure we discussed that before and some people did not agree.
>>>>
>>>> cheers,
>>>> Torsten
>>>>
>>>>
>>>>>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org> wrote:
>>>>>>
>>>>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>>>>
>>>>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>>>>
>>>>>>> - loosen API compatibility policy?
>>>>>
>>>>>> This topic alone deserves its own thread I think.
>>>>>
>>>>>> Ensuring binary/source compatibility is very important.
>>>>>
>>>>> +1
>>>>>
>>>>> I guess I've done too much ruby with "every bundle update runs the risk
>>>>> of breaking everything" lately. I really value the stability commons
>>>>> provides.
>>>>>
>>>>> That being said, I'm sure there are cases where our policy seems
>>>>> stricter than it needs to be - even though I haven't seen a really
>>>>> difficult case in the one component I contribute to.
>>>>>
>>>>> Stefan
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Gary,
A new major release requires a new package name, site, build and so on - think of commons-lang v1,2,3
Cheers,
Siegfried Goeschl
> Am 08.10.2013 um 22:54 schrieb Gary Gregory <ga...@gmail.com>:
>
> On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl
> <si...@it20one.at> wrote:
>> That's a reasonable style of versioning :)
>>
>> I had many issues with binary compatibilty with a commons-email release due to changing the return value from void to a this reference plus some moving of constants. You basically end up with either many restrictions or creating major releases
>
> Then just create major releases! ;) Why would you not want to provide
> BC? Why add to the jar hell problem? I, the developer, have no control
> over how the API I provide will be used and distributed...
>
> G
>
>>
>> Cheers,
>>
>> Siegfried Goeschl
>>
>>> Am 08.10.2013 um 12:40 schrieb Torsten Curdt <tc...@vafer.org>:
>>>
>>> Cannot remember which component from the top of my head - but it was
>>> related to package name changes.
>>>
>>> My style of thinking: x.y.z
>>>
>>> x - no compatibility
>>> y - source compatibility
>>> z - binary compatibility
>>>
>>> is simple and makes sense.
>>>
>>> It's OK to put some burden on the users when upgrading - as long as the
>>> expectations are set correctly.
>>> But I am pretty sure we discussed that before and some people did not agree.
>>>
>>> cheers,
>>> Torsten
>>>
>>>
>>>>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org> wrote:
>>>>>
>>>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>>>
>>>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>>>
>>>>>> - loosen API compatibility policy?
>>>>
>>>>> This topic alone deserves its own thread I think.
>>>>
>>>>> Ensuring binary/source compatibility is very important.
>>>>
>>>> +1
>>>>
>>>> I guess I've done too much ruby with "every bundle update runs the risk
>>>> of breaking everything" lately. I really value the stability commons
>>>> provides.
>>>>
>>>> That being said, I'm sure there are cases where our policy seems
>>>> stricter than it needs to be - even though I haven't seen a really
>>>> difficult case in the one component I contribute to.
>>>>
>>>> Stefan
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl
<si...@it20one.at> wrote:
> That's a reasonable style of versioning :)
>
> I had many issues with binary compatibilty with a commons-email release due to changing the return value from void to a this reference plus some moving of constants. You basically end up with either many restrictions or creating major releases
Then just create major releases! ;) Why would you not want to provide
BC? Why add to the jar hell problem? I, the developer, have no control
over how the API I provide will be used and distributed...
G
>
> Cheers,
>
> Siegfried Goeschl
>
>> Am 08.10.2013 um 12:40 schrieb Torsten Curdt <tc...@vafer.org>:
>>
>> Cannot remember which component from the top of my head - but it was
>> related to package name changes.
>>
>> My style of thinking: x.y.z
>>
>> x - no compatibility
>> y - source compatibility
>> z - binary compatibility
>>
>> is simple and makes sense.
>>
>> It's OK to put some burden on the users when upgrading - as long as the
>> expectations are set correctly.
>> But I am pretty sure we discussed that before and some people did not agree.
>>
>> cheers,
>> Torsten
>>
>>
>>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org> wrote:
>>>
>>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>>
>>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>>
>>>>> - loosen API compatibility policy?
>>>
>>>> This topic alone deserves its own thread I think.
>>>
>>>> Ensuring binary/source compatibility is very important.
>>>
>>> +1
>>>
>>> I guess I've done too much ruby with "every bundle update runs the risk
>>> of breaking everything" lately. I really value the stability commons
>>> provides.
>>>
>>> That being said, I'm sure there are cases where our policy seems
>>> stricter than it needs to be - even though I haven't seen a really
>>> difficult case in the one component I contribute to.
>>>
>>> Stefan
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Siegfried Goeschl <si...@it20one.at>.
That's a reasonable style of versioning :)
I had many issues with binary compatibilty with a commons-email release due to changing the return value from void to a this reference plus some moving of constants. You basically end up with either many restrictions or creating major releases
Cheers,
Siegfried Goeschl
> Am 08.10.2013 um 12:40 schrieb Torsten Curdt <tc...@vafer.org>:
>
> Cannot remember which component from the top of my head - but it was
> related to package name changes.
>
> My style of thinking: x.y.z
>
> x - no compatibility
> y - source compatibility
> z - binary compatibility
>
> is simple and makes sense.
>
> It's OK to put some burden on the users when upgrading - as long as the
> expectations are set correctly.
> But I am pretty sure we discussed that before and some people did not agree.
>
> cheers,
> Torsten
>
>
>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org> wrote:
>>
>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>
>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>
>>>> - loosen API compatibility policy?
>>
>>> This topic alone deserves its own thread I think.
>>
>>> Ensuring binary/source compatibility is very important.
>>
>> +1
>>
>> I guess I've done too much ruby with "every bundle update runs the risk
>> of breaking everything" lately. I really value the stability commons
>> provides.
>>
>> That being said, I'm sure there are cases where our policy seems
>> stricter than it needs to be - even though I haven't seen a really
>> difficult case in the one component I contribute to.
>>
>> Stefan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Christian Grobmeier <gr...@gmail.com>.
On 8 Oct 2013, at 12:48, James Carman wrote:
> I think the idea is to change the mindset. There seems to be an
> almost
> militant desire to maintain compatibility. Yes, we have the version
> number
> scheme, but some folks just never want to break compatibility it
> seems.
> This stalls innovation. I don't want to debate every change, so
> setting
> the expectations up-front is a good idea.
+1
> On Tuesday, October 8, 2013, Torsten Curdt wrote:
>> My style of thinking: x.y.z
>>
>> x - no compatibility
>> y - source compatibility
>> z - binary compatibility
>>
>> is simple and makes sense.
+1
I think its more or less semver: semver.org
>> It's OK to put some burden on the users when upgrading - as long as
>> the
>> expectations are set correctly.
>> But I am pretty sure we discussed that before and some people did not
>> agree.
Yes, and thats pretty bad because we cannot innovate any more.
I say: if we have people who want to maintain older version, go for it.
But please
let's stop blocking committers who want to do work a major change which
is not compatible.
If there are only people willing to work on the next major than to
maintain old versions
it is a bit sad, but thats life.
Christian
>>
>> cheers,
>> Torsten
>>
>>
>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig
>> <bodewig@apache.org<javascript:;>>
>> wrote:
>>
>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>
>>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>>
>>>>> - loosen API compatibility policy?
>>>
>>>> This topic alone deserves its own thread I think.
>>>
>>>> Ensuring binary/source compatibility is very important.
>>>
>>> +1
>>>
>>> I guess I've done too much ruby with "every bundle update runs the
>>> risk
>>> of breaking everything" lately. I really value the stability
>>> commons
>>> provides.
>>>
>>> That being said, I'm sure there are cases where our policy seems
>>> stricter than it needs to be - even though I haven't seen a really
>>> difficult case in the one component I contribute to.
>>>
>>> Stefan
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@commons.apache.org<javascript:;>
>>> For additional commands, e-mail:
>>> dev-help@commons.apache.org<javascript:;>
>>>
>>>
>>
---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by James Carman <ja...@carmanconsulting.com>.
I think the idea is to change the mindset. There seems to be an almost
militant desire to maintain compatibility. Yes, we have the version number
scheme, but some folks just never want to break compatibility it seems.
This stalls innovation. I don't want to debate every change, so setting
the expectations up-front is a good idea.
On Tuesday, October 8, 2013, Torsten Curdt wrote:
> Cannot remember which component from the top of my head - but it was
> related to package name changes.
>
> My style of thinking: x.y.z
>
> x - no compatibility
> y - source compatibility
> z - binary compatibility
>
> is simple and makes sense.
>
> It's OK to put some burden on the users when upgrading - as long as the
> expectations are set correctly.
> But I am pretty sure we discussed that before and some people did not
> agree.
>
> cheers,
> Torsten
>
>
> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bodewig@apache.org<javascript:;>>
> wrote:
>
> > On 2013-10-08, Emmanuel Bourg wrote:
> >
> > > Le 07/10/2013 20:14, Benedikt Ritter a écrit :
> >
> > >> - loosen API compatibility policy?
> >
> > > This topic alone deserves its own thread I think.
> >
> > > Ensuring binary/source compatibility is very important.
> >
> > +1
> >
> > I guess I've done too much ruby with "every bundle update runs the risk
> > of breaking everything" lately. I really value the stability commons
> > provides.
> >
> > That being said, I'm sure there are cases where our policy seems
> > stricter than it needs to be - even though I haven't seen a really
> > difficult case in the one component I contribute to.
> >
> > Stefan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org<javascript:;>
> > For additional commands, e-mail: dev-help@commons.apache.org<javascript:;>
> >
> >
>
Re: [DISCUSS] API compatibility policy
Posted by Torsten Curdt <tc...@vafer.org>.
Cannot remember which component from the top of my head - but it was
related to package name changes.
My style of thinking: x.y.z
x - no compatibility
y - source compatibility
z - binary compatibility
is simple and makes sense.
It's OK to put some burden on the users when upgrading - as long as the
expectations are set correctly.
But I am pretty sure we discussed that before and some people did not agree.
cheers,
Torsten
On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org> wrote:
> On 2013-10-08, Emmanuel Bourg wrote:
>
> > Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>
> >> - loosen API compatibility policy?
>
> > This topic alone deserves its own thread I think.
>
> > Ensuring binary/source compatibility is very important.
>
> +1
>
> I guess I've done too much ruby with "every bundle update runs the risk
> of breaking everything" lately. I really value the stability commons
> provides.
>
> That being said, I'm sure there are cases where our policy seems
> stricter than it needs to be - even though I haven't seen a really
> difficult case in the one component I contribute to.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [DISCUSS] API compatibility policy
Posted by Stefan Bodewig <bo...@apache.org>.
On 2013-10-08, Emmanuel Bourg wrote:
> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>> - loosen API compatibility policy?
> This topic alone deserves its own thread I think.
> Ensuring binary/source compatibility is very important.
+1
I guess I've done too much ruby with "every bundle update runs the risk
of breaking everything" lately. I really value the stability commons
provides.
That being said, I'm sure there are cases where our policy seems
stricter than it needs to be - even though I haven't seen a really
difficult case in the one component I contribute to.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 07/10/2013 20:14, Benedikt Ritter a écrit :
> - loosen API compatibility policy?
This topic alone deserves its own thread I think.
Ensuring binary/source compatibility is very important. This is an area
where Guava is clearly not a good example, they deprecate and remove
stuff frequently. Every time I update the Debian package for Guava I
know this will break reverse dependencies, I have to fix it and convince
the upstream projects to upgrade as well. On the other hand updating a
Commons component is just a breeze.
That being said, I think we are too strict on the compatibility rules.
Some incompatible changes are much less risky than others. For example,
adding a new method in an interface released less than 6 months ago
shouldn't be vetoed, but renaming public methods in a code that has been
in the wild for years shouldn't happen.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by Ate Douma <at...@douma.nu>.
On 10/07/2013 08:14 PM, Benedikt Ritter wrote:
> Hi,
>
> since we have discussed a lot of different aspects, it may be time to sum
> things up a bit (please correct me or add things I've missed):
>
> Release Management - Releases take too long
> - Build is overly complex
> - dependencies to parent pom seem to be unclear
> - to few releases (more releases may attract more people)
>
> Technical/Coding Stuff - Commons feels legacy
> - Using old JDKs simply isn't fun
> - people are moving to alternative libs (for example guava) because commons
> feels like legacy code
> - switching to git (?!)
>
> Organisational Stuff - to few people work on to many components
> - Split up commons into several TLPs
> - Split up commons into bigger sub projects with individual MLs
> - decide what can be dormant and focus on core components
>
> Etiquette/Policies - we are a do-ocracy
> - discussions are started instead of fixing it yourself (specially in
> sandbox)
> - we don't have to be perfect (and we will never be ;-)
> - loosen API compatibility policy?
>
> I personally would like to at the point about commons public relations I've
> talked about a while back. Seriously: if you look at our website do you get
> the feeling that bleeding edge software is developed at commons? I intended
> to do something about the site but got caught up in the site build and then
> lost the motivation to dig deeper into the issue (which I'm a bit ashamed
> of, now that I've to spell it out loud ;-)
>
> The question is: how do we want to address these issues. I've seen endless
> discussions here with no result. That's another problem I see. When we get
> started with discussing, a lot of ideas come up, but little action is taken
> in the end.
I've only been lurking here for a while, so I don't have yet first hand
experience of these problems (here), and probably a bit naive because of that.
But my experience in other ASF communities is that many of such endless
discussions with no result can be prevented by allowing a more lazy consensus
process, combined with more effective honoring a do-ocracy policy (those who do
decide).
People with an itch willing to scratch it should just propose to do so.
And unless someone with a reasonable argument *and* alternative objects, be
allowed to execute it. That should get stuff moving much faster *and* be
motivating for others with an itch to start scratching as well.
Objecting against a reasonable proposal without being able to step in yourself
doesn't help any project or community forward. Nor does it align with the
'Apache way'. If you don't have the time or interest to chime in and help, step
aside and make room for others who do.
'Community over code' really is key. For me at least that is the most important
'thing' making the ASF so great to be part of.
Thanks, Ate
>
> Benedikt
>
>
> 2013/10/7 James Carman <ja...@carmanconsulting.com>
>
>> On Sun, Oct 6, 2013 at 3:44 PM, Christian Grobmeier <gr...@gmail.com>
>> wrote:
>>>
>>> We discuss magic strings in the sandbox. Why? We don't need to discuss
>> that.
>>> Before we release we can simply check Sonar. Safe the time to discuss.
>> Fix
>>> it or leave it to Sonar to report it.
>>>
>>
>> +1! This sort of behavior definitely has to stop. It frustrates our
>> contributors. Nobody wants to get into lengthy discussions about this
>> level of minutiae. I know some folks have given up, because they
>> don't want to have to debate every little change they make. We vote
>> people in because they have the technical chops and have proven
>> themselves. They don't need a babysitter! Perhaps we should all
>> watch this video:
>>
>> http://www.youtube.com/watch?v=Q52kFL8zVoM
>>
>> Don't get me wrong, I am glad to know that we have people so dedicated
>> to the project that they are willing to monitor every single commit
>> message that comes through (I don't have that kind of time), but
>> perhaps that time would be better spent coding. If you see something
>> you think needs more documentation, then go document it. If you think
>> a refactoring is in order (like introducing a constant, extract
>> method, etc.), then go do it. Don't spend more of your time (and
>> theirs) writing up emails telling someone else to do it. Do it
>> yourself!
>>
>> For me, if you *have* to document your code, then you've failed. Your
>> code should be self-documenting. Comments eventually get out of sync
>> with the code and then you've got one big mess on your hands. Write
>> clear, elegant code and you don't have to worry about documentation.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by Benedikt Ritter <br...@apache.org>.
Hi,
since we have discussed a lot of different aspects, it may be time to sum
things up a bit (please correct me or add things I've missed):
Release Management - Releases take too long
- Build is overly complex
- dependencies to parent pom seem to be unclear
- to few releases (more releases may attract more people)
Technical/Coding Stuff - Commons feels legacy
- Using old JDKs simply isn't fun
- people are moving to alternative libs (for example guava) because commons
feels like legacy code
- switching to git (?!)
Organisational Stuff - to few people work on to many components
- Split up commons into several TLPs
- Split up commons into bigger sub projects with individual MLs
- decide what can be dormant and focus on core components
Etiquette/Policies - we are a do-ocracy
- discussions are started instead of fixing it yourself (specially in
sandbox)
- we don't have to be perfect (and we will never be ;-)
- loosen API compatibility policy?
I personally would like to at the point about commons public relations I've
talked about a while back. Seriously: if you look at our website do you get
the feeling that bleeding edge software is developed at commons? I intended
to do something about the site but got caught up in the site build and then
lost the motivation to dig deeper into the issue (which I'm a bit ashamed
of, now that I've to spell it out loud ;-)
The question is: how do we want to address these issues. I've seen endless
discussions here with no result. That's another problem I see. When we get
started with discussing, a lot of ideas come up, but little action is taken
in the end.
Benedikt
2013/10/7 James Carman <ja...@carmanconsulting.com>
> On Sun, Oct 6, 2013 at 3:44 PM, Christian Grobmeier <gr...@gmail.com>
> wrote:
> >
> > We discuss magic strings in the sandbox. Why? We don't need to discuss
> that.
> > Before we release we can simply check Sonar. Safe the time to discuss.
> Fix
> > it or leave it to Sonar to report it.
> >
>
> +1! This sort of behavior definitely has to stop. It frustrates our
> contributors. Nobody wants to get into lengthy discussions about this
> level of minutiae. I know some folks have given up, because they
> don't want to have to debate every little change they make. We vote
> people in because they have the technical chops and have proven
> themselves. They don't need a babysitter! Perhaps we should all
> watch this video:
>
> http://www.youtube.com/watch?v=Q52kFL8zVoM
>
> Don't get me wrong, I am glad to know that we have people so dedicated
> to the project that they are willing to monitor every single commit
> message that comes through (I don't have that kind of time), but
> perhaps that time would be better spent coding. If you see something
> you think needs more documentation, then go document it. If you think
> a refactoring is in order (like introducing a constant, extract
> method, etc.), then go do it. Don't spend more of your time (and
> theirs) writing up emails telling someone else to do it. Do it
> yourself!
>
> For me, if you *have* to document your code, then you've failed. Your
> code should be self-documenting. Comments eventually get out of sync
> with the code and then you've got one big mess on your hands. Write
> clear, elegant code and you don't have to worry about documentation.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [DISCUSS] Mission Statement for Commons...
Posted by James Carman <ja...@carmanconsulting.com>.
On Sun, Oct 6, 2013 at 3:44 PM, Christian Grobmeier <gr...@gmail.com> wrote:
>
> We discuss magic strings in the sandbox. Why? We don't need to discuss that.
> Before we release we can simply check Sonar. Safe the time to discuss. Fix
> it or leave it to Sonar to report it.
>
+1! This sort of behavior definitely has to stop. It frustrates our
contributors. Nobody wants to get into lengthy discussions about this
level of minutiae. I know some folks have given up, because they
don't want to have to debate every little change they make. We vote
people in because they have the technical chops and have proven
themselves. They don't need a babysitter! Perhaps we should all
watch this video:
http://www.youtube.com/watch?v=Q52kFL8zVoM
Don't get me wrong, I am glad to know that we have people so dedicated
to the project that they are willing to monitor every single commit
message that comes through (I don't have that kind of time), but
perhaps that time would be better spent coding. If you see something
you think needs more documentation, then go document it. If you think
a refactoring is in order (like introducing a constant, extract
method, etc.), then go do it. Don't spend more of your time (and
theirs) writing up emails telling someone else to do it. Do it
yourself!
For me, if you *have* to document your code, then you've failed. Your
code should be self-documenting. Comments eventually get out of sync
with the code and then you've got one big mess on your hands. Write
clear, elegant code and you don't have to worry about documentation.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by Matt Benson <gu...@gmail.com>.
I'd be fine with that, personally.
Matt
On Sun, Oct 6, 2013 at 4:05 PM, James Carman <ja...@carmanconsulting.com>wrote:
> How about we just switch to git, Matt? Many projects have already
> gone that route.
>
>
> On Sun, Oct 6, 2013 at 5:01 PM, Matt Benson <gu...@gmail.com> wrote:
> > Of the various tasks that are part of keeping Commons going: making
> > releases, pushing to the website, etc., I feel like there are maybe a
> > couple of people who feel confident to do each task, and they're probably
> > not the same people for each task. I think it could be helpful to
> > establish a list of what items there are that routinely need doing, and
> who
> > knows how to do them *and is willing to help others understand a given
> > process.* Making releases seems to be a big pain point--can we identify
> > what the problems are and improve or fix them? Is there any of us who
> > feels super-comfortable with releasing? Maybe that person could help
> e.g.
> > me over IRC next time I want to cut a release. Hopefully then I'll be
> more
> > comfortable and can try to help the next person. Similarly, I suspect
> that
> > some of us are now doing Commons dev using git-svn, and I have the
> feeling
> > it would be easier to merge github pull requests using git--is there
> anyone
> > willing and able to help me if I run into trouble experimenting with
> this?
> >
> > I do think that more than one component has had the wind taken out of its
> > sails by too much "back seat driving": anyone, committer or not, should
> > feel free to voice his opinion on any design decision, but that needs to
> be
> > tempered with a respect for the process of do-ocracy. If you're not
> > willing to actually step up and do the work, and can't convince
> > someone-who-is that your concern is important enough that they *want* to
> > take care of it, don't be surprised when it doesn't get done. At this
> > point we'd be better off releasing imperfect code. Bad code and good
> > communities, as they say... don't most of us begin participating in OSS
> > because we're using a library that's *almost good enough* if we could
> just
> > get that one bugfix or feature that we want so badly we write it
> ourselves?
> > Our obsession with perfection may be killing us in two ways: one, we
> > don't release anything, and two, if we ever did, it would be so perfect
> > there'd be nothing for a newcomer to contribute! ;)
> >
> > Matt
> >
> >
> > On Sun, Oct 6, 2013 at 3:37 PM, Jean-Louis MONTEIRO <jeanouii@gmail.com
> >wrote:
> >
> >> +1, looks like there are plenty of examples.
> >> Agree with Phil, how could we make things lighter or easier?
> >>
> >> I mean to get more release out.
> >>
> >> Jean-Louis
> >>
> >>
> >> 2013/10/6 Phil Steitz <ph...@gmail.com>
> >>
> >> >
> >> >
> >> > > On Oct 6, 2013, at 1:11 PM, Oliver Heger <
> oliver.heger@oliver-heger.de
> >> >
> >> > wrote:
> >> > >
> >> > > Hi Christian,
> >> > >
> >> > > Am 06.10.2013 21:44, schrieb Christian Grobmeier:
> >> > >> James,
> >> > >>
> >> > >> thank you.
> >> > >>
> >> > >> I believe Commons is in a bad shape.
> >> > >>
> >> > >> Look at Commons Collections. Before 4 years somebody
> >> > >> said Guava is more modern, he his answer seems to be widely
> accepted.
> >> > >> http://stackoverflow.com/a/1444467/690771
> >> > >> This guy said we have no generics. What did we do in the past 4
> years?
> >> > >>
> >> >
> >>
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22commons-collections%22%20AND%20a%3A%22commons-collections%22
> >> > >>
> >> > >>
> >> > >> Nothing. At least nothing visible. Its fine we have a beta. I
> wonder
> >> why
> >> > >> we haven't managed
> >> > >> to officially release this? The last release is from 2008.
> >> > >>
> >> > >> I did consider to put my JSON component to Commons. But I didn't.
> >> > >> Reason: I really need the component
> >> > >> and I calculated how long it would take to release it here. I
> thought,
> >> > >> it's not helping me
> >> > >> to develop it here. I simply don't have the time.
> >> > >>
> >> > >> I thought a long while about it.
> >> > >>
> >> > >> We had discussions like: do we really need Generics? It works
> without!
> >> > >> Do we really drop an outdated JDK? We might have users
> >> > >> who run JDK 1.3! And so on. Finally this led us to the situation
> where
> >> > >> almost all of our users seem to have JDK 1.3 and
> >> > >> are not interested in generics - in 2013. The users who want modern
> >> > >> features go to Guava. We maintain legacy code. And seriously, a
> lot of
> >> > >> code works without generics. This is no reason to not include them.
> >> > >>
> >> > >> We discuss magic strings in the sandbox. Why? We don't need to
> discuss
> >> > >> that. Before we release we can simply check Sonar. Safe the time to
> >> > >> discuss. Fix it or leave it to Sonar to report it.
> >> > >>
> >> > >> We seem to think perfect documentation is more valuable then quick
> >> > >> releases. Is it?
> >> > >>
> >> > >> We seem to be proud of our build. I am not. It's complex. It's no
> fun.
> >> > >> Releases should be do-able in a short time, maybe
> >> > >> even automated.
> >> > >>
> >> > >> It is so sad that lot of good features like Collections with
> Generics
> >> > >> were blocked such a long time or drowning in discussions.
> >> > >>
> >> > >> I agree we should support old users. But if we don't have the
> >> manpower,
> >> > >> we can't support them. They need to accept we are moving on. We are
> >> > >> blocked with our backwards compatible ideas and innovation is far
> >> away.
> >> > >>
> >> > >> When I spoke to young developers about Commons they asked me if it
> >> still
> >> > >> exists. Nobody of them is interested in our community.
> >> > >>
> >> > >> For the mission statement I would wish to see things like that:
> >> > >>
> >> > >> Commons Components…
> >> > >>
> >> > >> …are released quickly and often
> >> > >> …do use modern JDKs and support old JDKs only as long as they are
> >> > >> supported by Oracle
> >> > >> …we make use of modern Java features when they are available
> >> > >> …can be easily released
> >> > >> …can be released without having 100% perfect documentation or
> perfect
> >> > >> implementations
> >> > >> …are build by Community who wants to learn, experiment and create
> new
> >> > >> features more than by Community which wants to be backwards
> compatible
> >> > >> for a long time
> >> > >> …are allowed to release major versions with api breaks as they want
> >> > >>
> >> > >> Cheers
> >> > >> Christian
> >> > > I agree with many of your points. Another example is [csv] which is
> >> > > about to be released for ages. Here, I think, the main impediment is
> >> > > that we try to come up with a *perfect* API because due to our
> rules of
> >> > > backwards compatibility it is so difficult to correct any mistakes
> >> later.
> >> > >
> >> > > I still think that backwards compatibility is very important, but we
> >> > > really should define a process which allows us to experiment with
> new
> >> > APIs.
> >> > >
> >> > > As a suggestion to improve this situation, could we agree on an
> alpha
> >> > > release process allowing us to push releases with the aim of getting
> >> > > community feedback? Where we explicitly state that incompatible
> changes
> >> > > are possible (and likely)?
> >> > >
> >> > > We did something similar with [collections] 4, but there were many
> >> > > limitations (the release was not allowed to be uploaded to Maven
> >> central
> >> > > for instance). If we did such experimental releases more often,
> there
> >> > > would hopefully not be the fear of defining a broken API, and we
> would
> >> > > see more releases.
> >> >
> >> > +1 let's agree on how to do alphas.
> >> >
> >> > Phil
> >> > >
> >> > > Oliver
> >> > >
> >> > >>
> >> > >>> On 6 Oct 2013, at 20:30, James Carman wrote:
> >> > >>>
> >> > >>> All,
> >> > >>>
> >> > >>> The Apache Commons project seems to be languishing as of late and
> we
> >> > >>> need some rejuvenation. Perhaps we should try to define our
> mission
> >> > >>> as a project. What are our goals? What do we want to accomplish?
> >> > >>> Who are our users/customers? What non-functional qualities do we
> >> want
> >> > >>> our software to exhibit? How do we want to conduct ourselves?
> How
> >> > >>> often do we want to do releases? What else?
> >> > >>>
> >> > >>> Sincerely,
> >> > >>>
> >> > >>> James
> >> > >>>
> >> > >>>
> ---------------------------------------------------------------------
> >> > >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> > >>> For additional commands, e-mail: dev-help@commons.apache.org
> >> > >>
> >> > >>
> >> > >> ---
> >> > >> http://www.grobmeier.de
> >> > >> @grobmeier
> >> > >> GPG: 0xA5CC90DB
> >> > >>
> >> > >>
> ---------------------------------------------------------------------
> >> > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> > >> For additional commands, e-mail: dev-help@commons.apache.org
> >> > >
> >> > >
> >> > >
> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> > > For additional commands, e-mail: dev-help@commons.apache.org
> >> > >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> > For additional commands, e-mail: dev-help@commons.apache.org
> >> >
> >> >
> >>
> >>
> >> --
> >> Jean-Louis
> >>
>
Re: [DISCUSS] Mission Statement for Commons...
Posted by James Carman <ja...@carmanconsulting.com>.
How about we just switch to git, Matt? Many projects have already
gone that route.
On Sun, Oct 6, 2013 at 5:01 PM, Matt Benson <gu...@gmail.com> wrote:
> Of the various tasks that are part of keeping Commons going: making
> releases, pushing to the website, etc., I feel like there are maybe a
> couple of people who feel confident to do each task, and they're probably
> not the same people for each task. I think it could be helpful to
> establish a list of what items there are that routinely need doing, and who
> knows how to do them *and is willing to help others understand a given
> process.* Making releases seems to be a big pain point--can we identify
> what the problems are and improve or fix them? Is there any of us who
> feels super-comfortable with releasing? Maybe that person could help e.g.
> me over IRC next time I want to cut a release. Hopefully then I'll be more
> comfortable and can try to help the next person. Similarly, I suspect that
> some of us are now doing Commons dev using git-svn, and I have the feeling
> it would be easier to merge github pull requests using git--is there anyone
> willing and able to help me if I run into trouble experimenting with this?
>
> I do think that more than one component has had the wind taken out of its
> sails by too much "back seat driving": anyone, committer or not, should
> feel free to voice his opinion on any design decision, but that needs to be
> tempered with a respect for the process of do-ocracy. If you're not
> willing to actually step up and do the work, and can't convince
> someone-who-is that your concern is important enough that they *want* to
> take care of it, don't be surprised when it doesn't get done. At this
> point we'd be better off releasing imperfect code. Bad code and good
> communities, as they say... don't most of us begin participating in OSS
> because we're using a library that's *almost good enough* if we could just
> get that one bugfix or feature that we want so badly we write it ourselves?
> Our obsession with perfection may be killing us in two ways: one, we
> don't release anything, and two, if we ever did, it would be so perfect
> there'd be nothing for a newcomer to contribute! ;)
>
> Matt
>
>
> On Sun, Oct 6, 2013 at 3:37 PM, Jean-Louis MONTEIRO <je...@gmail.com>wrote:
>
>> +1, looks like there are plenty of examples.
>> Agree with Phil, how could we make things lighter or easier?
>>
>> I mean to get more release out.
>>
>> Jean-Louis
>>
>>
>> 2013/10/6 Phil Steitz <ph...@gmail.com>
>>
>> >
>> >
>> > > On Oct 6, 2013, at 1:11 PM, Oliver Heger <oliver.heger@oliver-heger.de
>> >
>> > wrote:
>> > >
>> > > Hi Christian,
>> > >
>> > > Am 06.10.2013 21:44, schrieb Christian Grobmeier:
>> > >> James,
>> > >>
>> > >> thank you.
>> > >>
>> > >> I believe Commons is in a bad shape.
>> > >>
>> > >> Look at Commons Collections. Before 4 years somebody
>> > >> said Guava is more modern, he his answer seems to be widely accepted.
>> > >> http://stackoverflow.com/a/1444467/690771
>> > >> This guy said we have no generics. What did we do in the past 4 years?
>> > >>
>> >
>> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22commons-collections%22%20AND%20a%3A%22commons-collections%22
>> > >>
>> > >>
>> > >> Nothing. At least nothing visible. Its fine we have a beta. I wonder
>> why
>> > >> we haven't managed
>> > >> to officially release this? The last release is from 2008.
>> > >>
>> > >> I did consider to put my JSON component to Commons. But I didn't.
>> > >> Reason: I really need the component
>> > >> and I calculated how long it would take to release it here. I thought,
>> > >> it's not helping me
>> > >> to develop it here. I simply don't have the time.
>> > >>
>> > >> I thought a long while about it.
>> > >>
>> > >> We had discussions like: do we really need Generics? It works without!
>> > >> Do we really drop an outdated JDK? We might have users
>> > >> who run JDK 1.3! And so on. Finally this led us to the situation where
>> > >> almost all of our users seem to have JDK 1.3 and
>> > >> are not interested in generics - in 2013. The users who want modern
>> > >> features go to Guava. We maintain legacy code. And seriously, a lot of
>> > >> code works without generics. This is no reason to not include them.
>> > >>
>> > >> We discuss magic strings in the sandbox. Why? We don't need to discuss
>> > >> that. Before we release we can simply check Sonar. Safe the time to
>> > >> discuss. Fix it or leave it to Sonar to report it.
>> > >>
>> > >> We seem to think perfect documentation is more valuable then quick
>> > >> releases. Is it?
>> > >>
>> > >> We seem to be proud of our build. I am not. It's complex. It's no fun.
>> > >> Releases should be do-able in a short time, maybe
>> > >> even automated.
>> > >>
>> > >> It is so sad that lot of good features like Collections with Generics
>> > >> were blocked such a long time or drowning in discussions.
>> > >>
>> > >> I agree we should support old users. But if we don't have the
>> manpower,
>> > >> we can't support them. They need to accept we are moving on. We are
>> > >> blocked with our backwards compatible ideas and innovation is far
>> away.
>> > >>
>> > >> When I spoke to young developers about Commons they asked me if it
>> still
>> > >> exists. Nobody of them is interested in our community.
>> > >>
>> > >> For the mission statement I would wish to see things like that:
>> > >>
>> > >> Commons Components…
>> > >>
>> > >> …are released quickly and often
>> > >> …do use modern JDKs and support old JDKs only as long as they are
>> > >> supported by Oracle
>> > >> …we make use of modern Java features when they are available
>> > >> …can be easily released
>> > >> …can be released without having 100% perfect documentation or perfect
>> > >> implementations
>> > >> …are build by Community who wants to learn, experiment and create new
>> > >> features more than by Community which wants to be backwards compatible
>> > >> for a long time
>> > >> …are allowed to release major versions with api breaks as they want
>> > >>
>> > >> Cheers
>> > >> Christian
>> > > I agree with many of your points. Another example is [csv] which is
>> > > about to be released for ages. Here, I think, the main impediment is
>> > > that we try to come up with a *perfect* API because due to our rules of
>> > > backwards compatibility it is so difficult to correct any mistakes
>> later.
>> > >
>> > > I still think that backwards compatibility is very important, but we
>> > > really should define a process which allows us to experiment with new
>> > APIs.
>> > >
>> > > As a suggestion to improve this situation, could we agree on an alpha
>> > > release process allowing us to push releases with the aim of getting
>> > > community feedback? Where we explicitly state that incompatible changes
>> > > are possible (and likely)?
>> > >
>> > > We did something similar with [collections] 4, but there were many
>> > > limitations (the release was not allowed to be uploaded to Maven
>> central
>> > > for instance). If we did such experimental releases more often, there
>> > > would hopefully not be the fear of defining a broken API, and we would
>> > > see more releases.
>> >
>> > +1 let's agree on how to do alphas.
>> >
>> > Phil
>> > >
>> > > Oliver
>> > >
>> > >>
>> > >>> On 6 Oct 2013, at 20:30, James Carman wrote:
>> > >>>
>> > >>> All,
>> > >>>
>> > >>> The Apache Commons project seems to be languishing as of late and we
>> > >>> need some rejuvenation. Perhaps we should try to define our mission
>> > >>> as a project. What are our goals? What do we want to accomplish?
>> > >>> Who are our users/customers? What non-functional qualities do we
>> want
>> > >>> our software to exhibit? How do we want to conduct ourselves? How
>> > >>> often do we want to do releases? What else?
>> > >>>
>> > >>> Sincerely,
>> > >>>
>> > >>> James
>> > >>>
>> > >>> ---------------------------------------------------------------------
>> > >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > >>> For additional commands, e-mail: dev-help@commons.apache.org
>> > >>
>> > >>
>> > >> ---
>> > >> http://www.grobmeier.de
>> > >> @grobmeier
>> > >> GPG: 0xA5CC90DB
>> > >>
>> > >> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > >> For additional commands, e-mail: dev-help@commons.apache.org
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > > For additional commands, e-mail: dev-help@commons.apache.org
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>> >
>>
>>
>> --
>> Jean-Louis
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by Matt Benson <gu...@gmail.com>.
Of the various tasks that are part of keeping Commons going: making
releases, pushing to the website, etc., I feel like there are maybe a
couple of people who feel confident to do each task, and they're probably
not the same people for each task. I think it could be helpful to
establish a list of what items there are that routinely need doing, and who
knows how to do them *and is willing to help others understand a given
process.* Making releases seems to be a big pain point--can we identify
what the problems are and improve or fix them? Is there any of us who
feels super-comfortable with releasing? Maybe that person could help e.g.
me over IRC next time I want to cut a release. Hopefully then I'll be more
comfortable and can try to help the next person. Similarly, I suspect that
some of us are now doing Commons dev using git-svn, and I have the feeling
it would be easier to merge github pull requests using git--is there anyone
willing and able to help me if I run into trouble experimenting with this?
I do think that more than one component has had the wind taken out of its
sails by too much "back seat driving": anyone, committer or not, should
feel free to voice his opinion on any design decision, but that needs to be
tempered with a respect for the process of do-ocracy. If you're not
willing to actually step up and do the work, and can't convince
someone-who-is that your concern is important enough that they *want* to
take care of it, don't be surprised when it doesn't get done. At this
point we'd be better off releasing imperfect code. Bad code and good
communities, as they say... don't most of us begin participating in OSS
because we're using a library that's *almost good enough* if we could just
get that one bugfix or feature that we want so badly we write it ourselves?
Our obsession with perfection may be killing us in two ways: one, we
don't release anything, and two, if we ever did, it would be so perfect
there'd be nothing for a newcomer to contribute! ;)
Matt
On Sun, Oct 6, 2013 at 3:37 PM, Jean-Louis MONTEIRO <je...@gmail.com>wrote:
> +1, looks like there are plenty of examples.
> Agree with Phil, how could we make things lighter or easier?
>
> I mean to get more release out.
>
> Jean-Louis
>
>
> 2013/10/6 Phil Steitz <ph...@gmail.com>
>
> >
> >
> > > On Oct 6, 2013, at 1:11 PM, Oliver Heger <oliver.heger@oliver-heger.de
> >
> > wrote:
> > >
> > > Hi Christian,
> > >
> > > Am 06.10.2013 21:44, schrieb Christian Grobmeier:
> > >> James,
> > >>
> > >> thank you.
> > >>
> > >> I believe Commons is in a bad shape.
> > >>
> > >> Look at Commons Collections. Before 4 years somebody
> > >> said Guava is more modern, he his answer seems to be widely accepted.
> > >> http://stackoverflow.com/a/1444467/690771
> > >> This guy said we have no generics. What did we do in the past 4 years?
> > >>
> >
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22commons-collections%22%20AND%20a%3A%22commons-collections%22
> > >>
> > >>
> > >> Nothing. At least nothing visible. Its fine we have a beta. I wonder
> why
> > >> we haven't managed
> > >> to officially release this? The last release is from 2008.
> > >>
> > >> I did consider to put my JSON component to Commons. But I didn't.
> > >> Reason: I really need the component
> > >> and I calculated how long it would take to release it here. I thought,
> > >> it's not helping me
> > >> to develop it here. I simply don't have the time.
> > >>
> > >> I thought a long while about it.
> > >>
> > >> We had discussions like: do we really need Generics? It works without!
> > >> Do we really drop an outdated JDK? We might have users
> > >> who run JDK 1.3! And so on. Finally this led us to the situation where
> > >> almost all of our users seem to have JDK 1.3 and
> > >> are not interested in generics - in 2013. The users who want modern
> > >> features go to Guava. We maintain legacy code. And seriously, a lot of
> > >> code works without generics. This is no reason to not include them.
> > >>
> > >> We discuss magic strings in the sandbox. Why? We don't need to discuss
> > >> that. Before we release we can simply check Sonar. Safe the time to
> > >> discuss. Fix it or leave it to Sonar to report it.
> > >>
> > >> We seem to think perfect documentation is more valuable then quick
> > >> releases. Is it?
> > >>
> > >> We seem to be proud of our build. I am not. It's complex. It's no fun.
> > >> Releases should be do-able in a short time, maybe
> > >> even automated.
> > >>
> > >> It is so sad that lot of good features like Collections with Generics
> > >> were blocked such a long time or drowning in discussions.
> > >>
> > >> I agree we should support old users. But if we don't have the
> manpower,
> > >> we can't support them. They need to accept we are moving on. We are
> > >> blocked with our backwards compatible ideas and innovation is far
> away.
> > >>
> > >> When I spoke to young developers about Commons they asked me if it
> still
> > >> exists. Nobody of them is interested in our community.
> > >>
> > >> For the mission statement I would wish to see things like that:
> > >>
> > >> Commons Components…
> > >>
> > >> …are released quickly and often
> > >> …do use modern JDKs and support old JDKs only as long as they are
> > >> supported by Oracle
> > >> …we make use of modern Java features when they are available
> > >> …can be easily released
> > >> …can be released without having 100% perfect documentation or perfect
> > >> implementations
> > >> …are build by Community who wants to learn, experiment and create new
> > >> features more than by Community which wants to be backwards compatible
> > >> for a long time
> > >> …are allowed to release major versions with api breaks as they want
> > >>
> > >> Cheers
> > >> Christian
> > > I agree with many of your points. Another example is [csv] which is
> > > about to be released for ages. Here, I think, the main impediment is
> > > that we try to come up with a *perfect* API because due to our rules of
> > > backwards compatibility it is so difficult to correct any mistakes
> later.
> > >
> > > I still think that backwards compatibility is very important, but we
> > > really should define a process which allows us to experiment with new
> > APIs.
> > >
> > > As a suggestion to improve this situation, could we agree on an alpha
> > > release process allowing us to push releases with the aim of getting
> > > community feedback? Where we explicitly state that incompatible changes
> > > are possible (and likely)?
> > >
> > > We did something similar with [collections] 4, but there were many
> > > limitations (the release was not allowed to be uploaded to Maven
> central
> > > for instance). If we did such experimental releases more often, there
> > > would hopefully not be the fear of defining a broken API, and we would
> > > see more releases.
> >
> > +1 let's agree on how to do alphas.
> >
> > Phil
> > >
> > > Oliver
> > >
> > >>
> > >>> On 6 Oct 2013, at 20:30, James Carman wrote:
> > >>>
> > >>> All,
> > >>>
> > >>> The Apache Commons project seems to be languishing as of late and we
> > >>> need some rejuvenation. Perhaps we should try to define our mission
> > >>> as a project. What are our goals? What do we want to accomplish?
> > >>> Who are our users/customers? What non-functional qualities do we
> want
> > >>> our software to exhibit? How do we want to conduct ourselves? How
> > >>> often do we want to do releases? What else?
> > >>>
> > >>> Sincerely,
> > >>>
> > >>> James
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >>> For additional commands, e-mail: dev-help@commons.apache.org
> > >>
> > >>
> > >> ---
> > >> http://www.grobmeier.de
> > >> @grobmeier
> > >> GPG: 0xA5CC90DB
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> Jean-Louis
>
Re: [DISCUSS] Mission Statement for Commons...
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
+1, looks like there are plenty of examples.
Agree with Phil, how could we make things lighter or easier?
I mean to get more release out.
Jean-Louis
2013/10/6 Phil Steitz <ph...@gmail.com>
>
>
> > On Oct 6, 2013, at 1:11 PM, Oliver Heger <ol...@oliver-heger.de>
> wrote:
> >
> > Hi Christian,
> >
> > Am 06.10.2013 21:44, schrieb Christian Grobmeier:
> >> James,
> >>
> >> thank you.
> >>
> >> I believe Commons is in a bad shape.
> >>
> >> Look at Commons Collections. Before 4 years somebody
> >> said Guava is more modern, he his answer seems to be widely accepted.
> >> http://stackoverflow.com/a/1444467/690771
> >> This guy said we have no generics. What did we do in the past 4 years?
> >>
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22commons-collections%22%20AND%20a%3A%22commons-collections%22
> >>
> >>
> >> Nothing. At least nothing visible. Its fine we have a beta. I wonder why
> >> we haven't managed
> >> to officially release this? The last release is from 2008.
> >>
> >> I did consider to put my JSON component to Commons. But I didn't.
> >> Reason: I really need the component
> >> and I calculated how long it would take to release it here. I thought,
> >> it's not helping me
> >> to develop it here. I simply don't have the time.
> >>
> >> I thought a long while about it.
> >>
> >> We had discussions like: do we really need Generics? It works without!
> >> Do we really drop an outdated JDK? We might have users
> >> who run JDK 1.3! And so on. Finally this led us to the situation where
> >> almost all of our users seem to have JDK 1.3 and
> >> are not interested in generics - in 2013. The users who want modern
> >> features go to Guava. We maintain legacy code. And seriously, a lot of
> >> code works without generics. This is no reason to not include them.
> >>
> >> We discuss magic strings in the sandbox. Why? We don't need to discuss
> >> that. Before we release we can simply check Sonar. Safe the time to
> >> discuss. Fix it or leave it to Sonar to report it.
> >>
> >> We seem to think perfect documentation is more valuable then quick
> >> releases. Is it?
> >>
> >> We seem to be proud of our build. I am not. It's complex. It's no fun.
> >> Releases should be do-able in a short time, maybe
> >> even automated.
> >>
> >> It is so sad that lot of good features like Collections with Generics
> >> were blocked such a long time or drowning in discussions.
> >>
> >> I agree we should support old users. But if we don't have the manpower,
> >> we can't support them. They need to accept we are moving on. We are
> >> blocked with our backwards compatible ideas and innovation is far away.
> >>
> >> When I spoke to young developers about Commons they asked me if it still
> >> exists. Nobody of them is interested in our community.
> >>
> >> For the mission statement I would wish to see things like that:
> >>
> >> Commons Components…
> >>
> >> …are released quickly and often
> >> …do use modern JDKs and support old JDKs only as long as they are
> >> supported by Oracle
> >> …we make use of modern Java features when they are available
> >> …can be easily released
> >> …can be released without having 100% perfect documentation or perfect
> >> implementations
> >> …are build by Community who wants to learn, experiment and create new
> >> features more than by Community which wants to be backwards compatible
> >> for a long time
> >> …are allowed to release major versions with api breaks as they want
> >>
> >> Cheers
> >> Christian
> > I agree with many of your points. Another example is [csv] which is
> > about to be released for ages. Here, I think, the main impediment is
> > that we try to come up with a *perfect* API because due to our rules of
> > backwards compatibility it is so difficult to correct any mistakes later.
> >
> > I still think that backwards compatibility is very important, but we
> > really should define a process which allows us to experiment with new
> APIs.
> >
> > As a suggestion to improve this situation, could we agree on an alpha
> > release process allowing us to push releases with the aim of getting
> > community feedback? Where we explicitly state that incompatible changes
> > are possible (and likely)?
> >
> > We did something similar with [collections] 4, but there were many
> > limitations (the release was not allowed to be uploaded to Maven central
> > for instance). If we did such experimental releases more often, there
> > would hopefully not be the fear of defining a broken API, and we would
> > see more releases.
>
> +1 let's agree on how to do alphas.
>
> Phil
> >
> > Oliver
> >
> >>
> >>> On 6 Oct 2013, at 20:30, James Carman wrote:
> >>>
> >>> All,
> >>>
> >>> The Apache Commons project seems to be languishing as of late and we
> >>> need some rejuvenation. Perhaps we should try to define our mission
> >>> as a project. What are our goals? What do we want to accomplish?
> >>> Who are our users/customers? What non-functional qualities do we want
> >>> our software to exhibit? How do we want to conduct ourselves? How
> >>> often do we want to do releases? What else?
> >>>
> >>> Sincerely,
> >>>
> >>> James
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >> ---
> >> http://www.grobmeier.de
> >> @grobmeier
> >> GPG: 0xA5CC90DB
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Jean-Louis
Re: [DISCUSS] Mission Statement for Commons...
Posted by Phil Steitz <ph...@gmail.com>.
> On Oct 6, 2013, at 1:11 PM, Oliver Heger <ol...@oliver-heger.de> wrote:
>
> Hi Christian,
>
> Am 06.10.2013 21:44, schrieb Christian Grobmeier:
>> James,
>>
>> thank you.
>>
>> I believe Commons is in a bad shape.
>>
>> Look at Commons Collections. Before 4 years somebody
>> said Guava is more modern, he his answer seems to be widely accepted.
>> http://stackoverflow.com/a/1444467/690771
>> This guy said we have no generics. What did we do in the past 4 years?
>> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22commons-collections%22%20AND%20a%3A%22commons-collections%22
>>
>>
>> Nothing. At least nothing visible. Its fine we have a beta. I wonder why
>> we haven't managed
>> to officially release this? The last release is from 2008.
>>
>> I did consider to put my JSON component to Commons. But I didn't.
>> Reason: I really need the component
>> and I calculated how long it would take to release it here. I thought,
>> it's not helping me
>> to develop it here. I simply don't have the time.
>>
>> I thought a long while about it.
>>
>> We had discussions like: do we really need Generics? It works without!
>> Do we really drop an outdated JDK? We might have users
>> who run JDK 1.3! And so on. Finally this led us to the situation where
>> almost all of our users seem to have JDK 1.3 and
>> are not interested in generics - in 2013. The users who want modern
>> features go to Guava. We maintain legacy code. And seriously, a lot of
>> code works without generics. This is no reason to not include them.
>>
>> We discuss magic strings in the sandbox. Why? We don't need to discuss
>> that. Before we release we can simply check Sonar. Safe the time to
>> discuss. Fix it or leave it to Sonar to report it.
>>
>> We seem to think perfect documentation is more valuable then quick
>> releases. Is it?
>>
>> We seem to be proud of our build. I am not. It's complex. It's no fun.
>> Releases should be do-able in a short time, maybe
>> even automated.
>>
>> It is so sad that lot of good features like Collections with Generics
>> were blocked such a long time or drowning in discussions.
>>
>> I agree we should support old users. But if we don't have the manpower,
>> we can't support them. They need to accept we are moving on. We are
>> blocked with our backwards compatible ideas and innovation is far away.
>>
>> When I spoke to young developers about Commons they asked me if it still
>> exists. Nobody of them is interested in our community.
>>
>> For the mission statement I would wish to see things like that:
>>
>> Commons Components…
>>
>> …are released quickly and often
>> …do use modern JDKs and support old JDKs only as long as they are
>> supported by Oracle
>> …we make use of modern Java features when they are available
>> …can be easily released
>> …can be released without having 100% perfect documentation or perfect
>> implementations
>> …are build by Community who wants to learn, experiment and create new
>> features more than by Community which wants to be backwards compatible
>> for a long time
>> …are allowed to release major versions with api breaks as they want
>>
>> Cheers
>> Christian
> I agree with many of your points. Another example is [csv] which is
> about to be released for ages. Here, I think, the main impediment is
> that we try to come up with a *perfect* API because due to our rules of
> backwards compatibility it is so difficult to correct any mistakes later.
>
> I still think that backwards compatibility is very important, but we
> really should define a process which allows us to experiment with new APIs.
>
> As a suggestion to improve this situation, could we agree on an alpha
> release process allowing us to push releases with the aim of getting
> community feedback? Where we explicitly state that incompatible changes
> are possible (and likely)?
>
> We did something similar with [collections] 4, but there were many
> limitations (the release was not allowed to be uploaded to Maven central
> for instance). If we did such experimental releases more often, there
> would hopefully not be the fear of defining a broken API, and we would
> see more releases.
+1 let's agree on how to do alphas.
Phil
>
> Oliver
>
>>
>>> On 6 Oct 2013, at 20:30, James Carman wrote:
>>>
>>> All,
>>>
>>> The Apache Commons project seems to be languishing as of late and we
>>> need some rejuvenation. Perhaps we should try to define our mission
>>> as a project. What are our goals? What do we want to accomplish?
>>> Who are our users/customers? What non-functional qualities do we want
>>> our software to exhibit? How do we want to conduct ourselves? How
>>> often do we want to do releases? What else?
>>>
>>> Sincerely,
>>>
>>> James
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>> ---
>> http://www.grobmeier.de
>> @grobmeier
>> GPG: 0xA5CC90DB
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by Oliver Heger <ol...@oliver-heger.de>.
Hi Christian,
Am 06.10.2013 21:44, schrieb Christian Grobmeier:
> James,
>
> thank you.
>
> I believe Commons is in a bad shape.
>
> Look at Commons Collections. Before 4 years somebody
> said Guava is more modern, he his answer seems to be widely accepted.
> http://stackoverflow.com/a/1444467/690771
> This guy said we have no generics. What did we do in the past 4 years?
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22commons-collections%22%20AND%20a%3A%22commons-collections%22
>
>
> Nothing. At least nothing visible. Its fine we have a beta. I wonder why
> we haven't managed
> to officially release this? The last release is from 2008.
>
> I did consider to put my JSON component to Commons. But I didn't.
> Reason: I really need the component
> and I calculated how long it would take to release it here. I thought,
> it's not helping me
> to develop it here. I simply don't have the time.
>
> I thought a long while about it.
>
> We had discussions like: do we really need Generics? It works without!
> Do we really drop an outdated JDK? We might have users
> who run JDK 1.3! And so on. Finally this led us to the situation where
> almost all of our users seem to have JDK 1.3 and
> are not interested in generics - in 2013. The users who want modern
> features go to Guava. We maintain legacy code. And seriously, a lot of
> code works without generics. This is no reason to not include them.
>
> We discuss magic strings in the sandbox. Why? We don't need to discuss
> that. Before we release we can simply check Sonar. Safe the time to
> discuss. Fix it or leave it to Sonar to report it.
>
> We seem to think perfect documentation is more valuable then quick
> releases. Is it?
>
> We seem to be proud of our build. I am not. It's complex. It's no fun.
> Releases should be do-able in a short time, maybe
> even automated.
>
> It is so sad that lot of good features like Collections with Generics
> were blocked such a long time or drowning in discussions.
>
> I agree we should support old users. But if we don't have the manpower,
> we can't support them. They need to accept we are moving on. We are
> blocked with our backwards compatible ideas and innovation is far away.
>
> When I spoke to young developers about Commons they asked me if it still
> exists. Nobody of them is interested in our community.
>
> For the mission statement I would wish to see things like that:
>
> Commons Components…
>
> …are released quickly and often
> …do use modern JDKs and support old JDKs only as long as they are
> supported by Oracle
> …we make use of modern Java features when they are available
> …can be easily released
> …can be released without having 100% perfect documentation or perfect
> implementations
> …are build by Community who wants to learn, experiment and create new
> features more than by Community which wants to be backwards compatible
> for a long time
> …are allowed to release major versions with api breaks as they want
>
> Cheers
> Christian
>
>
I agree with many of your points. Another example is [csv] which is
about to be released for ages. Here, I think, the main impediment is
that we try to come up with a *perfect* API because due to our rules of
backwards compatibility it is so difficult to correct any mistakes later.
I still think that backwards compatibility is very important, but we
really should define a process which allows us to experiment with new APIs.
As a suggestion to improve this situation, could we agree on an alpha
release process allowing us to push releases with the aim of getting
community feedback? Where we explicitly state that incompatible changes
are possible (and likely)?
We did something similar with [collections] 4, but there were many
limitations (the release was not allowed to be uploaded to Maven central
for instance). If we did such experimental releases more often, there
would hopefully not be the fear of defining a broken API, and we would
see more releases.
Oliver
>
> On 6 Oct 2013, at 20:30, James Carman wrote:
>
>> All,
>>
>> The Apache Commons project seems to be languishing as of late and we
>> need some rejuvenation. Perhaps we should try to define our mission
>> as a project. What are our goals? What do we want to accomplish?
>> Who are our users/customers? What non-functional qualities do we want
>> our software to exhibit? How do we want to conduct ourselves? How
>> often do we want to do releases? What else?
>>
>> Sincerely,
>>
>> James
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---
> http://www.grobmeier.de
> @grobmeier
> GPG: 0xA5CC90DB
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by Thomas Neidhart <th...@gmail.com>.
On 10/06/2013 09:44 PM, Christian Grobmeier wrote:
> James,
>
> thank you.
>
> I believe Commons is in a bad shape.
>
> Look at Commons Collections. Before 4 years somebody
> said Guava is more modern, he his answer seems to be widely accepted.
> http://stackoverflow.com/a/1444467/690771
> This guy said we have no generics. What did we do in the past 4 years?
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22commons-collections%22%20AND%20a%3A%22commons-collections%22
>
>
> Nothing. At least nothing visible. Its fine we have a beta. I wonder why
> we haven't managed
> to officially release this? The last release is from 2008.
>
> I did consider to put my JSON component to Commons. But I didn't.
> Reason: I really need the component
> and I calculated how long it would take to release it here. I thought,
> it's not helping me
> to develop it here. I simply don't have the time.
>
> I thought a long while about it.
>
> We had discussions like: do we really need Generics? It works without!
> Do we really drop an outdated JDK? We might have users
> who run JDK 1.3! And so on. Finally this led us to the situation where
> almost all of our users seem to have JDK 1.3 and
> are not interested in generics - in 2013. The users who want modern
> features go to Guava. We maintain legacy code. And seriously, a lot of
> code works without generics. This is no reason to not include them.
>
> We discuss magic strings in the sandbox. Why? We don't need to discuss
> that. Before we release we can simply check Sonar. Safe the time to
> discuss. Fix it or leave it to Sonar to report it.
>
> We seem to think perfect documentation is more valuable then quick
> releases. Is it?
>
> We seem to be proud of our build. I am not. It's complex. It's no fun.
> Releases should be do-able in a short time, maybe
> even automated.
>
> It is so sad that lot of good features like Collections with Generics
> were blocked such a long time or drowning in discussions.
>
> I agree we should support old users. But if we don't have the manpower,
> we can't support them. They need to accept we are moving on. We are
> blocked with our backwards compatible ideas and innovation is far away.
>
> When I spoke to young developers about Commons they asked me if it still
> exists. Nobody of them is interested in our community.
>
> For the mission statement I would wish to see things like that:
>
> Commons Components…
>
> …are released quickly and often
> …do use modern JDKs and support old JDKs only as long as they are
> supported by Oracle
> …we make use of modern Java features when they are available
> …can be easily released
> …can be released without having 100% perfect documentation or perfect
> implementations
> …are build by Community who wants to learn, experiment and create new
> features more than by Community which wants to be backwards compatible
> for a long time
> …are allowed to release major versions with api breaks as they want
+1 on all the points above.
And I would also like to repeat again that we should not be too afraid
to make components dormant which have no community anymore and / or have
not seen a release in X years.
If new people show up and want to revive a component - perfect, but we
should better focus our sparse resources on things that are innovative
and widely used.
>From my personal experience, it is also much more fun to work with
multiple people on a component and being able to have discussions on the
mailing list rather than being the sole remaining committer / maintainer.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by Luc Maisonobe <Lu...@free.fr>.
Hi all,
Le 06/10/2013 21:44, Christian Grobmeier a écrit :
> James,
>
> thank you.
>
> I believe Commons is in a bad shape.
>
> Look at Commons Collections. Before 4 years somebody
> said Guava is more modern, he his answer seems to be widely accepted.
> http://stackoverflow.com/a/1444467/690771
> This guy said we have no generics. What did we do in the past 4 years?
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22commons-collections%22%20AND%20a%3A%22commons-collections%22
>
>
> Nothing. At least nothing visible. Its fine we have a beta. I wonder why
> we haven't managed
> to officially release this? The last release is from 2008.
>
> I did consider to put my JSON component to Commons. But I didn't.
> Reason: I really need the component
> and I calculated how long it would take to release it here. I thought,
> it's not helping me
> to develop it here. I simply don't have the time.
>
> I thought a long while about it.
>
> We had discussions like: do we really need Generics? It works without!
> Do we really drop an outdated JDK? We might have users
> who run JDK 1.3! And so on. Finally this led us to the situation where
> almost all of our users seem to have JDK 1.3 and
> are not interested in generics - in 2013. The users who want modern
> features go to Guava. We maintain legacy code. And seriously, a lot of
> code works without generics. This is no reason to not include them.
>
> We discuss magic strings in the sandbox. Why? We don't need to discuss
> that. Before we release we can simply check Sonar. Safe the time to
> discuss. Fix it or leave it to Sonar to report it.
>
> We seem to think perfect documentation is more valuable then quick
> releases. Is it?
>
> We seem to be proud of our build. I am not. It's complex. It's no fun.
> Releases should be do-able in a short time, maybe
> even automated.
>
> It is so sad that lot of good features like Collections with Generics
> were blocked such a long time or drowning in discussions.
>
> I agree we should support old users. But if we don't have the manpower,
> we can't support them. They need to accept we are moving on. We are
> blocked with our backwards compatible ideas and innovation is far away.
>
> When I spoke to young developers about Commons they asked me if it still
> exists. Nobody of them is interested in our community.
>
> For the mission statement I would wish to see things like that:
>
> Commons Components…
>
> …are released quickly and often
Big, +1.
> …do use modern JDKs and support old JDKs only as long as they are
> supported by Oracle
+0. They may use older JDK if they want, but should not be too
conservative on this.
> …we make use of modern Java features when they are available
+0. Same as above
> …can be easily released
+1
> …can be released without having 100% perfect documentation or perfect
> implementations
+1
> …are build by Community who wants to learn, experiment and create new
> features more than by Community which wants to be backwards compatible
> for a long time
+1, and see below.
> …are allowed to release major versions with api breaks as they want
Well, this is already the case.
I think we should even go further and allow "some" API breaks in minor
versions. We suffer a lot from our own too stringent compatibility in
[math]. Experience shows that when we introduce new features, we make
mistakes and we need to fix them in the next release but cannot due to
compatibility. The irony being we must remain compatible with API design
errors ...
Of course, always breaking important public API is bad, but for example
adding some methods to existing interfaces (which would force users
providing their own implementations) may be allowed in some cases,
typically when the interface is not really meant to be implemented by
users themselves but is rather a convenience for our own interfaces, or
when the changes are really simple.
Luc
>
> Cheers
> Christian
>
>
>
> On 6 Oct 2013, at 20:30, James Carman wrote:
>
>> All,
>>
>> The Apache Commons project seems to be languishing as of late and we
>> need some rejuvenation. Perhaps we should try to define our mission
>> as a project. What are our goals? What do we want to accomplish?
>> Who are our users/customers? What non-functional qualities do we want
>> our software to exhibit? How do we want to conduct ourselves? How
>> often do we want to do releases? What else?
>>
>> Sincerely,
>>
>> James
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---
> http://www.grobmeier.de
> @grobmeier
> GPG: 0xA5CC90DB
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by Christian Grobmeier <gr...@gmail.com>.
James,
thank you.
I believe Commons is in a bad shape.
Look at Commons Collections. Before 4 years somebody
said Guava is more modern, he his answer seems to be widely accepted.
http://stackoverflow.com/a/1444467/690771
This guy said we have no generics. What did we do in the past 4 years?
http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22commons-collections%22%20AND%20a%3A%22commons-collections%22
Nothing. At least nothing visible. Its fine we have a beta. I wonder why
we haven't managed
to officially release this? The last release is from 2008.
I did consider to put my JSON component to Commons. But I didn't.
Reason: I really need the component
and I calculated how long it would take to release it here. I thought,
it's not helping me
to develop it here. I simply don't have the time.
I thought a long while about it.
We had discussions like: do we really need Generics? It works without!
Do we really drop an outdated JDK? We might have users
who run JDK 1.3! And so on. Finally this led us to the situation where
almost all of our users seem to have JDK 1.3 and
are not interested in generics - in 2013. The users who want modern
features go to Guava. We maintain legacy code. And seriously, a lot of
code works without generics. This is no reason to not include them.
We discuss magic strings in the sandbox. Why? We don't need to discuss
that. Before we release we can simply check Sonar. Safe the time to
discuss. Fix it or leave it to Sonar to report it.
We seem to think perfect documentation is more valuable then quick
releases. Is it?
We seem to be proud of our build. I am not. It's complex. It's no fun.
Releases should be do-able in a short time, maybe
even automated.
It is so sad that lot of good features like Collections with Generics
were blocked such a long time or drowning in discussions.
I agree we should support old users. But if we don't have the manpower,
we can't support them. They need to accept we are moving on. We are
blocked with our backwards compatible ideas and innovation is far away.
When I spoke to young developers about Commons they asked me if it still
exists. Nobody of them is interested in our community.
For the mission statement I would wish to see things like that:
Commons Components…
…are released quickly and often
…do use modern JDKs and support old JDKs only as long as they are
supported by Oracle
…we make use of modern Java features when they are available
…can be easily released
…can be released without having 100% perfect documentation or perfect
implementations
…are build by Community who wants to learn, experiment and create new
features more than by Community which wants to be backwards compatible
for a long time
…are allowed to release major versions with api breaks as they want
Cheers
Christian
On 6 Oct 2013, at 20:30, James Carman wrote:
> All,
>
> The Apache Commons project seems to be languishing as of late and we
> need some rejuvenation. Perhaps we should try to define our mission
> as a project. What are our goals? What do we want to accomplish?
> Who are our users/customers? What non-functional qualities do we want
> our software to exhibit? How do we want to conduct ourselves? How
> often do we want to do releases? What else?
>
> Sincerely,
>
> James
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1
Le 7 oct. 2013 12:58, "Jean-Louis MONTEIRO" <je...@gmail.com> a écrit :
> Hi Jochen,
>
> Well summarized.
> And I think you figured out what the real problem is.
>
> We could work as in Incubator, isn't it?
> Having one big umbrella and real subprojects.
>
>
>
> JLouis
>
>
> 2013/10/7 Jochen Wiedmann <jo...@gmail.com>
>
> > I believe that the problem is Commons structure. To have one big project
> > which such a lot of subprojects blocks building a small community. You're
> > not supposed to be a part of the small subproject, but the big community
> > "Commons". While the former would be appealing for a newcomer, the latter
> > just doesn't work (too many unknown people).
> >
> > I have no alternatives to offer, but my feeling is we should attempt to
> > build smaller, more centralized parts with separate mailing lists, etc.
> > Obviously, this might lead to a Jakarta-ization, but there are worse
> things
> > than being split into subprojects.
> >
> >
> >
> >
> >
> > On Sun, Oct 6, 2013 at 8:30 PM, James Carman <james@carmanconsulting.com
> > >wrote:
> >
> > > All,
> > >
> > > The Apache Commons project seems to be languishing as of late and we
> > > need some rejuvenation. Perhaps we should try to define our mission
> > > as a project. What are our goals? What do we want to accomplish?
> > > Who are our users/customers? What non-functional qualities do we want
> > > our software to exhibit? How do we want to conduct ourselves? How
> > > often do we want to do releases? What else?
> > >
> > > Sincerely,
> > >
> > > James
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> >
> > --
> > "That's what prayers are ... it's frightened people trying to make
> friends
> > with the bully!"
> >
> > Terry Pratchett. The Last Hero
> >
>
>
>
> --
> Jean-Louis
>
Re: [DISCUSS] Mission Statement for Commons...
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Mon, Oct 7, 2013 at 2:05 PM, Christian Grobmeier <gr...@gmail.com>wrote:
> On 7 Oct 2013, at 13:58, Jochen Wiedmann wrote:
>
> On Mon, Oct 7, 2013 at 1:42 PM, Christian Grobmeier <grobmeier@gmail.com
>> >wrote:
>>
>> What would be the difference to now?
>>>
>>>
>>> The difference can be *huge*, emotionally. For example, I felt quite at
>> home at the webservices project when working in JaxMe, XML-RPC, or Axis.
>> OTOH, I feel completely isolated, since ws-commons works like Commons.
>>
>
>
Most important: Alllow subprojects to have their own mailing list. There is
quite a difference between talking to an audience of 3-4 people, whom I
know, or believe to know, and dev@commons.
Jochen
Re: [DISCUSS] Mission Statement for Commons...
Posted by Christian Grobmeier <gr...@gmail.com>.
On 7 Oct 2013, at 13:58, Jochen Wiedmann wrote:
> On Mon, Oct 7, 2013 at 1:42 PM, Christian Grobmeier
> <gr...@gmail.com>wrote:
>
>> What would be the difference to now?
>>
>>
> The difference can be *huge*, emotionally. For example, I felt quite
> at
> home at the webservices project when working in JaxMe, XML-RPC, or
> Axis.
> OTOH, I feel completely isolated, since ws-commons works like Commons.
Let me ask different.
I think we already have an incubator like set up (just without
podling-pmcs), what needs to be changed?
>
>
>
>
> --
> "That's what prayers are ... it's frightened people trying to make
> friends
> with the bully!"
>
> Terry Pratchett. The Last Hero
---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Mon, Oct 7, 2013 at 1:42 PM, Christian Grobmeier <gr...@gmail.com>wrote:
> What would be the difference to now?
>
>
The difference can be *huge*, emotionally. For example, I felt quite at
home at the webservices project when working in JaxMe, XML-RPC, or Axis.
OTOH, I feel completely isolated, since ws-commons works like Commons.
--
"That's what prayers are ... it's frightened people trying to make friends
with the bully!"
Terry Pratchett. The Last Hero
Re: [DISCUSS] Mission Statement for Commons...
Posted by Christian Grobmeier <gr...@gmail.com>.
On 7 Oct 2013, at 12:58, Jean-Louis MONTEIRO wrote:
> Hi Jochen,
>
> Well summarized.
> And I think you figured out what the real problem is.
>
> We could work as in Incubator, isn't it?
> Having one big umbrella and real subprojects.
What would be the difference to now?
I understand Commons as a project with components which are not
big enough to survive as a tlp. A few components have overlapping
committers but not all. You can't make "sub-pmcs" similar to
podling-pmcs,
otherwise Commons quickly enters Jakarta land.
The only thing which we share all is the site build and the release
process
(both things i personally don't like too much).
If stepping in that direction we maybe should think about grouping sets
of projects like [Collections, Lang] or [Compress, IO] and make them a
TLP on their own.
This will show us if there is enough interest in those components on the
one
hand and reduce the PMC to the really interested people on the other.
For example, it is unlikely that I would ask to join the first group but
pretty sure
that I would ask to join the second.
Cheers
Christian
>
>
>
> JLouis
>
>
> 2013/10/7 Jochen Wiedmann <jo...@gmail.com>
>
>> I believe that the problem is Commons structure. To have one big
>> project
>> which such a lot of subprojects blocks building a small community.
>> You're
>> not supposed to be a part of the small subproject, but the big
>> community
>> "Commons". While the former would be appealing for a newcomer, the
>> latter
>> just doesn't work (too many unknown people).
>>
>> I have no alternatives to offer, but my feeling is we should attempt
>> to
>> build smaller, more centralized parts with separate mailing lists,
>> etc.
>> Obviously, this might lead to a Jakarta-ization, but there are worse
>> things
>> than being split into subprojects.
>>
>>
>>
>>
>>
>> On Sun, Oct 6, 2013 at 8:30 PM, James Carman
>> <james@carmanconsulting.com
>>> wrote:
>>
>>> All,
>>>
>>> The Apache Commons project seems to be languishing as of late and we
>>> need some rejuvenation. Perhaps we should try to define our mission
>>> as a project. What are our goals? What do we want to accomplish?
>>> Who are our users/customers? What non-functional qualities do we
>>> want
>>> our software to exhibit? How do we want to conduct ourselves? How
>>> often do we want to do releases? What else?
>>>
>>> Sincerely,
>>>
>>> James
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> --
>> "That's what prayers are ... it's frightened people trying to make
>> friends
>> with the bully!"
>>
>> Terry Pratchett. The Last Hero
>>
>
>
>
> --
> Jean-Louis
---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
Hi Jochen,
Well summarized.
And I think you figured out what the real problem is.
We could work as in Incubator, isn't it?
Having one big umbrella and real subprojects.
JLouis
2013/10/7 Jochen Wiedmann <jo...@gmail.com>
> I believe that the problem is Commons structure. To have one big project
> which such a lot of subprojects blocks building a small community. You're
> not supposed to be a part of the small subproject, but the big community
> "Commons". While the former would be appealing for a newcomer, the latter
> just doesn't work (too many unknown people).
>
> I have no alternatives to offer, but my feeling is we should attempt to
> build smaller, more centralized parts with separate mailing lists, etc.
> Obviously, this might lead to a Jakarta-ization, but there are worse things
> than being split into subprojects.
>
>
>
>
>
> On Sun, Oct 6, 2013 at 8:30 PM, James Carman <james@carmanconsulting.com
> >wrote:
>
> > All,
> >
> > The Apache Commons project seems to be languishing as of late and we
> > need some rejuvenation. Perhaps we should try to define our mission
> > as a project. What are our goals? What do we want to accomplish?
> > Who are our users/customers? What non-functional qualities do we want
> > our software to exhibit? How do we want to conduct ourselves? How
> > often do we want to do releases? What else?
> >
> > Sincerely,
> >
> > James
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> "That's what prayers are ... it's frightened people trying to make friends
> with the bully!"
>
> Terry Pratchett. The Last Hero
>
--
Jean-Louis
Re: [DISCUSS] Mission Statement for Commons...
Posted by Jochen Wiedmann <jo...@gmail.com>.
I believe that the problem is Commons structure. To have one big project
which such a lot of subprojects blocks building a small community. You're
not supposed to be a part of the small subproject, but the big community
"Commons". While the former would be appealing for a newcomer, the latter
just doesn't work (too many unknown people).
I have no alternatives to offer, but my feeling is we should attempt to
build smaller, more centralized parts with separate mailing lists, etc.
Obviously, this might lead to a Jakarta-ization, but there are worse things
than being split into subprojects.
On Sun, Oct 6, 2013 at 8:30 PM, James Carman <ja...@carmanconsulting.com>wrote:
> All,
>
> The Apache Commons project seems to be languishing as of late and we
> need some rejuvenation. Perhaps we should try to define our mission
> as a project. What are our goals? What do we want to accomplish?
> Who are our users/customers? What non-functional qualities do we want
> our software to exhibit? How do we want to conduct ourselves? How
> often do we want to do releases? What else?
>
> Sincerely,
>
> James
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
"That's what prayers are ... it's frightened people trying to make friends
with the bully!"
Terry Pratchett. The Last Hero
Re: [DISCUSS] Mission Statement for Commons...
Posted by James Carman <ja...@carmanconsulting.com>.
Let's take a look:
https://issues.apache.org/jira/browse/COLLECTIONS#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel
3.2.1 - 4/15/2008
3.2 - 5/14/2006
3.1 - 6/28/2004
We haven't had a release in over 5 years. The last one (which was a
point release) took two years roughly. Again, a minor release prior
to that took almost two years as well. We don't have a good track
record of releasing early and often.
On Sun, Oct 6, 2013 at 3:00 PM, James Carman <ja...@carmanconsulting.com> wrote:
> The fact that it has taken so long before we got something out for
> Collections 4.x is just an embarrassment. How long has Java had
> generics? What could be causing us to be so slow to get releases out?
>
>
> On Sun, Oct 6, 2013 at 2:57 PM, Phil Steitz <ph...@gmail.com> wrote:
>> On 10/6/13 11:45 AM, James Carman wrote:
>>> Collections 4.x, nuff said
>>
>> Huh? Didn't we release a beta? We could say the same thing about
>> math 4.0, pool/dbcp 2.0, etc. These things are in progress. They
>> will get released. There is activity. I don't get the big problem
>> here.
>>
>> Phil
>>>
>>>
>>> On Sun, Oct 6, 2013 at 2:42 PM, Adrian Crum
>>> <ad...@sandglass-software.com> wrote:
>>>> I would like to know the metrics for that conclusion. I see plenty of
>>>> discussions and commits, but I'm not seeing any languishing.
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>>
>>>> On 10/6/2013 11:30 AM, James Carman wrote:
>>>>> All,
>>>>>
>>>>> The Apache Commons project seems to be languishing as of late and we
>>>>> need some rejuvenation. Perhaps we should try to define our mission
>>>>> as a project. What are our goals? What do we want to accomplish?
>>>>> Who are our users/customers? What non-functional qualities do we want
>>>>> our software to exhibit? How do we want to conduct ourselves? How
>>>>> often do we want to do releases? What else?
>>>>>
>>>>> Sincerely,
>>>>>
>>>>> James
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by Olivier Lamy <ol...@apache.org>.
I agree on the "The release process has always been a little bit of a
pain in the butt".
As you say most of people are volunteers so they prefer working on fun
part (coding and adding a new features) rather than wasting time on
too much (non needed?) procedures.
Yup that can be a long discussion.... :-)
On 7 October 2013 07:46, Phil Steitz <ph...@gmail.com> wrote:
>
>
>> On Oct 6, 2013, at 12:00 PM, James Carman <ja...@carmanconsulting.com> wrote:
>>
>> The fact that it has taken so long before we got something out for
>> Collections 4.x is just an embarrassment. How long has Java had
>> generics? What could be causing us to be so slow to get releases out?
>
> I may be in the minority here, but I think the real problem is too many components for too few "committed committers". The release process has always been a little bit of a pain in the butt, but I've never felt blocked by it. What has taken so long on pool/DBCP is that it is just Mark and I really digging into the code and we are both busy with other stuff / have limited time to work on it. Like some other components, the code is also kind of specialized and the documentation is not the best, making it harder for others to get involved. Collections went nowhere for a couple of years because no one stepped up to drive it. Thankfully Thomas did recently and we got a 4.0 beta. The best thing anyone can do to get a real 4.0 out is start actually coding on it.
>
> I honestly think we are making excuses in this thread - the real problem is dwindling component communities. We need to decide which ones to ale dormant and make it easier for people to get involved in the active ones.
>
>
>>> On Sun, Oct 6, 2013 at 2:57 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>> On 10/6/13 11:45 AM, James Carman wrote:
>>>> Collections 4.x, nuff said
>>>
>>> Huh? Didn't we release a beta? We could say the same thing about
>>> math 4.0, pool/dbcp 2.0, etc. These things are in progress. They
>>> will get released. There is activity. I don't get the big problem
>>> here.
>>>
>>> Phil
>>>>
>>>>
>>>> On Sun, Oct 6, 2013 at 2:42 PM, Adrian Crum
>>>> <ad...@sandglass-software.com> wrote:
>>>>> I would like to know the metrics for that conclusion. I see plenty of
>>>>> discussions and commits, but I'm not seeing any languishing.
>>>>>
>>>>> Adrian Crum
>>>>> Sandglass Software
>>>>> www.sandglass-software.com
>>>>>
>>>>>
>>>>>> On 10/6/2013 11:30 AM, James Carman wrote:
>>>>>> All,
>>>>>>
>>>>>> The Apache Commons project seems to be languishing as of late and we
>>>>>> need some rejuvenation. Perhaps we should try to define our mission
>>>>>> as a project. What are our goals? What do we want to accomplish?
>>>>>> Who are our users/customers? What non-functional qualities do we want
>>>>>> our software to exhibit? How do we want to conduct ourselves? How
>>>>>> often do we want to do releases? What else?
>>>>>>
>>>>>> Sincerely,
>>>>>>
>>>>>> James
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by Phil Steitz <ph...@gmail.com>.
> On Oct 6, 2013, at 1:51 PM, James Carman <ja...@carmanconsulting.com> wrote:
>
> So, would you say we have a problem attracting new committers or are
> our current committers just losing interest (or a combination of
> both)?
I think it's both, but the first is natural / will always be happening. It's the second that we should focus on IMO - getting new people involved and progressing to become committers. Fattening up the subcommunities by existing committers agreeing to focus on a smaller number of components might help if that is possible. And being more open to Christian's points on new approaches / major branches.
Phil
>
>> On Sun, Oct 6, 2013 at 4:46 PM, Phil Steitz <ph...@gmail.com> wrote:
>>
>>
>>> On Oct 6, 2013, at 12:00 PM, James Carman <ja...@carmanconsulting.com> wrote:
>>>
>>> The fact that it has taken so long before we got something out for
>>> Collections 4.x is just an embarrassment. How long has Java had
>>> generics? What could be causing us to be so slow to get releases out?
>>
>> I may be in the minority here, but I think the real problem is too many components for too few "committed committers". The release process has always been a little bit of a pain in the butt, but I've never felt blocked by it. What has taken so long on pool/DBCP is that it is just Mark and I really digging into the code and we are both busy with other stuff / have limited time to work on it. Like some other components, the code is also kind of specialized and the documentation is not the best, making it harder for others to get involved. Collections went nowhere for a couple of years because no one stepped up to drive it. Thankfully Thomas did recently and we got a 4.0 beta. The best thing anyone can do to get a real 4.0 out is start actually coding on it.
>>
>> I honestly think we are making excuses in this thread - the real problem is dwindling component communities. We need to decide which ones to ale dormant and make it easier for people to get involved in the active ones.
>>
>>
>>>>> On Sun, Oct 6, 2013 at 2:57 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>> On 10/6/13 11:45 AM, James Carman wrote:
>>>>> Collections 4.x, nuff said
>>>>
>>>> Huh? Didn't we release a beta? We could say the same thing about
>>>> math 4.0, pool/dbcp 2.0, etc. These things are in progress. They
>>>> will get released. There is activity. I don't get the big problem
>>>> here.
>>>>
>>>> Phil
>>>>>
>>>>>
>>>>> On Sun, Oct 6, 2013 at 2:42 PM, Adrian Crum
>>>>> <ad...@sandglass-software.com> wrote:
>>>>>> I would like to know the metrics for that conclusion. I see plenty of
>>>>>> discussions and commits, but I'm not seeing any languishing.
>>>>>>
>>>>>> Adrian Crum
>>>>>> Sandglass Software
>>>>>> www.sandglass-software.com
>>>>>>
>>>>>>
>>>>>>> On 10/6/2013 11:30 AM, James Carman wrote:
>>>>>>> All,
>>>>>>>
>>>>>>> The Apache Commons project seems to be languishing as of late and we
>>>>>>> need some rejuvenation. Perhaps we should try to define our mission
>>>>>>> as a project. What are our goals? What do we want to accomplish?
>>>>>>> Who are our users/customers? What non-functional qualities do we want
>>>>>>> our software to exhibit? How do we want to conduct ourselves? How
>>>>>>> often do we want to do releases? What else?
>>>>>>>
>>>>>>> Sincerely,
>>>>>>>
>>>>>>> James
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by James Carman <ja...@carmanconsulting.com>.
So, would you say we have a problem attracting new committers or are
our current committers just losing interest (or a combination of
both)?
On Sun, Oct 6, 2013 at 4:46 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>
>> On Oct 6, 2013, at 12:00 PM, James Carman <ja...@carmanconsulting.com> wrote:
>>
>> The fact that it has taken so long before we got something out for
>> Collections 4.x is just an embarrassment. How long has Java had
>> generics? What could be causing us to be so slow to get releases out?
>
> I may be in the minority here, but I think the real problem is too many components for too few "committed committers". The release process has always been a little bit of a pain in the butt, but I've never felt blocked by it. What has taken so long on pool/DBCP is that it is just Mark and I really digging into the code and we are both busy with other stuff / have limited time to work on it. Like some other components, the code is also kind of specialized and the documentation is not the best, making it harder for others to get involved. Collections went nowhere for a couple of years because no one stepped up to drive it. Thankfully Thomas did recently and we got a 4.0 beta. The best thing anyone can do to get a real 4.0 out is start actually coding on it.
>
> I honestly think we are making excuses in this thread - the real problem is dwindling component communities. We need to decide which ones to ale dormant and make it easier for people to get involved in the active ones.
>
>
>>> On Sun, Oct 6, 2013 at 2:57 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>> On 10/6/13 11:45 AM, James Carman wrote:
>>>> Collections 4.x, nuff said
>>>
>>> Huh? Didn't we release a beta? We could say the same thing about
>>> math 4.0, pool/dbcp 2.0, etc. These things are in progress. They
>>> will get released. There is activity. I don't get the big problem
>>> here.
>>>
>>> Phil
>>>>
>>>>
>>>> On Sun, Oct 6, 2013 at 2:42 PM, Adrian Crum
>>>> <ad...@sandglass-software.com> wrote:
>>>>> I would like to know the metrics for that conclusion. I see plenty of
>>>>> discussions and commits, but I'm not seeing any languishing.
>>>>>
>>>>> Adrian Crum
>>>>> Sandglass Software
>>>>> www.sandglass-software.com
>>>>>
>>>>>
>>>>>> On 10/6/2013 11:30 AM, James Carman wrote:
>>>>>> All,
>>>>>>
>>>>>> The Apache Commons project seems to be languishing as of late and we
>>>>>> need some rejuvenation. Perhaps we should try to define our mission
>>>>>> as a project. What are our goals? What do we want to accomplish?
>>>>>> Who are our users/customers? What non-functional qualities do we want
>>>>>> our software to exhibit? How do we want to conduct ourselves? How
>>>>>> often do we want to do releases? What else?
>>>>>>
>>>>>> Sincerely,
>>>>>>
>>>>>> James
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by sebb <se...@gmail.com>.
On 6 October 2013 21:46, Phil Steitz <ph...@gmail.com> wrote:
>
>
>> On Oct 6, 2013, at 12:00 PM, James Carman <ja...@carmanconsulting.com> wrote:
>>
>> The fact that it has taken so long before we got something out for
>> Collections 4.x is just an embarrassment. How long has Java had
>> generics? What could be causing us to be so slow to get releases out?
>
In the case of Collections, I think part of the problem was that
several parts of the API were really difficult to convert to generics
satisfactorily.
I know I tried a year or two ago, but could not make adequate progress.
> I may be in the minority here, but I think the real problem is too many components for too few "committed committers". The release process has always been a little bit of a pain in the butt, but I've never felt blocked by it. What has taken so long on pool/DBCP is that it is just Mark and I really digging into the code and we are both busy with other stuff / have limited time to work on it. Like some other components, the code is also kind of specialized and the documentation is not the best, making it harder for others to get involved. Collections went nowhere for a couple of years because no one stepped up to drive it. Thankfully Thomas did recently and we got a 4.0 beta. The best thing anyone can do to get a real 4.0 out is start actually coding on it.
>
> I honestly think we are making excuses in this thread - the real problem is dwindling component communities. We need to decide which ones to ale dormant and make it easier for people to get involved in the active ones.
>
Very well put.
>
>>> On Sun, Oct 6, 2013 at 2:57 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>> On 10/6/13 11:45 AM, James Carman wrote:
>>>> Collections 4.x, nuff said
>>>
>>> Huh? Didn't we release a beta? We could say the same thing about
>>> math 4.0, pool/dbcp 2.0, etc. These things are in progress. They
>>> will get released. There is activity. I don't get the big problem
>>> here.
>>>
>>> Phil
>>>>
>>>>
>>>> On Sun, Oct 6, 2013 at 2:42 PM, Adrian Crum
>>>> <ad...@sandglass-software.com> wrote:
>>>>> I would like to know the metrics for that conclusion. I see plenty of
>>>>> discussions and commits, but I'm not seeing any languishing.
>>>>>
>>>>> Adrian Crum
>>>>> Sandglass Software
>>>>> www.sandglass-software.com
>>>>>
>>>>>
>>>>>> On 10/6/2013 11:30 AM, James Carman wrote:
>>>>>> All,
>>>>>>
>>>>>> The Apache Commons project seems to be languishing as of late and we
>>>>>> need some rejuvenation. Perhaps we should try to define our mission
>>>>>> as a project. What are our goals? What do we want to accomplish?
>>>>>> Who are our users/customers? What non-functional qualities do we want
>>>>>> our software to exhibit? How do we want to conduct ourselves? How
>>>>>> often do we want to do releases? What else?
>>>>>>
>>>>>> Sincerely,
>>>>>>
>>>>>> James
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by James Carman <ja...@carmanconsulting.com>.
On Sun, Oct 6, 2013 at 4:53 PM, Phil Steitz <ph...@gmail.com> wrote:
>
> S/ale/make (love that iPhone :)
>
You know, the iPhone studies what words you use most often and assumes
that's what you mean ;) LOL
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by Phil Steitz <ph...@gmail.com>.
> On Oct 6, 2013, at 2:28 PM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> Stupid question: couldnt commons be broken in real projects (tlp) without
> links (other than deps) between them? Would make them using adapted rules
> to their need
Not a stupid question. We have talked about it in the past. The problem is that probably only a handful would survive the "rule of 3" and replicating the overhead that we now share would not be appealing. Also as I said else-thread, we have traditionally given component sub communities pretty good freedom to operate as they see fit, so I am not sure there is much to gain from going tlp.
Phil
> Le 6 oct. 2013 23:25, "Dave Brosius" <db...@apache.org> a écrit :
>
>> Phil,
>>
>> You definitely have a point, but nothing helps build a development
>> community than seeing releases go out.
>>
>> "I want to be part of that"
>>
>> If there's no idea if or even when another version of a library will go
>> out, especially one that's hasn't released in a while, it deflates possible
>> joiners.
>>
>> Even if we *just* released generized versions of the existing versions and
>> nothing else, that would be really helpful, i think, in pulling in more
>> help.
>>
>> --dave
>>
>>
>>> On 10/06/2013 04:53 PM, Phil Steitz wrote:
>>>
>>>
>>>> On Oct 6, 2013, at 1:46 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>> On Oct 6, 2013, at 12:00 PM, James Carman <ja...@carmanconsulting.com>
>>>>> wrote:
>>>>>
>>>>> The fact that it has taken so long before we got something out for
>>>>> Collections 4.x is just an embarrassment. How long has Java had
>>>>> generics? What could be causing us to be so slow to get releases out?
>>>> I may be in the minority here, but I think the real problem is too many
>>>> components for too few "committed committers". The release process has
>>>> always been a little bit of a pain in the butt, but I've never felt blocked
>>>> by it. What has taken so long on pool/DBCP is that it is just Mark and I
>>>> really digging into the code and we are both busy with other stuff / have
>>>> limited time to work on it. Like some other components, the code is also
>>>> kind of specialized and the documentation is not the best, making it harder
>>>> for others to get involved. Collections went nowhere for a couple of years
>>>> because no one stepped up to drive it. Thankfully Thomas did recently and
>>>> we got a 4.0 beta. The best thing anyone can do to get a real 4.0 out is
>>>> start actually coding on it.
>>>>
>>>> I honestly think we are making excuses in this thread - the real problem
>>>> is dwindling component communities. We need to decide which ones to ale
>>>> dormant and make it easier for people to get involved in the active ones.
>>> S/ale/make (love that iPhone :)
>>>
>>>>
>>>> On Sun, Oct 6, 2013 at 2:57 PM, Phil Steitz <ph...@gmail.com>
>>>>>>> wrote:
>>>>>>> On 10/6/13 11:45 AM, James Carman wrote:
>>>>>>> Collections 4.x, nuff said
>>>>>> Huh? Didn't we release a beta? We could say the same thing about
>>>>>> math 4.0, pool/dbcp 2.0, etc. These things are in progress. They
>>>>>> will get released. There is activity. I don't get the big problem
>>>>>> here.
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>>>
>>>>>>> On Sun, Oct 6, 2013 at 2:42 PM, Adrian Crum
>>>>>>> <ad...@sandglass-software.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I would like to know the metrics for that conclusion. I see plenty of
>>>>>>>> discussions and commits, but I'm not seeing any languishing.
>>>>>>>>
>>>>>>>> Adrian Crum
>>>>>>>> Sandglass Software
>>>>>>>> www.sandglass-software.com
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 10/6/2013 11:30 AM, James Carman wrote:
>>>>>>>>> All,
>>>>>>>>>
>>>>>>>>> The Apache Commons project seems to be languishing as of late and we
>>>>>>>>> need some rejuvenation. Perhaps we should try to define our mission
>>>>>>>>> as a project. What are our goals? What do we want to accomplish?
>>>>>>>>> Who are our users/customers? What non-functional qualities do we
>>>>>>>>> want
>>>>>>>>> our software to exhibit? How do we want to conduct ourselves? How
>>>>>>>>> often do we want to do releases? What else?
>>>>>>>>>
>>>>>>>>> Sincerely,
>>>>>>>>>
>>>>>>>>> James
>>>>>>>>>
>>>>>>>>> ------------------------------**------------------------------**
>>>>>>>>> ---------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>> ------------------------------**------------------------------**
>>>>>>>> ---------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>> ------------------------------**------------------------------**
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>> ------------------------------**------------------------------**
>>>>>> ---------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>> ------------------------------**------------------------------**
>>>>> ---------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Stupid question: couldnt commons be broken in real projects (tlp) without
links (other than deps) between them? Would make them using adapted rules
to their need
Le 6 oct. 2013 23:25, "Dave Brosius" <db...@apache.org> a écrit :
> Phil,
>
> You definitely have a point, but nothing helps build a development
> community than seeing releases go out.
>
> "I want to be part of that"
>
> If there's no idea if or even when another version of a library will go
> out, especially one that's hasn't released in a while, it deflates possible
> joiners.
>
> Even if we *just* released generized versions of the existing versions and
> nothing else, that would be really helpful, i think, in pulling in more
> help.
>
> --dave
>
>
> On 10/06/2013 04:53 PM, Phil Steitz wrote:
>
>>
>> On Oct 6, 2013, at 1:46 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>
>>>
>>>
>>> On Oct 6, 2013, at 12:00 PM, James Carman <ja...@carmanconsulting.com>
>>>> wrote:
>>>>
>>>> The fact that it has taken so long before we got something out for
>>>> Collections 4.x is just an embarrassment. How long has Java had
>>>> generics? What could be causing us to be so slow to get releases out?
>>>>
>>> I may be in the minority here, but I think the real problem is too many
>>> components for too few "committed committers". The release process has
>>> always been a little bit of a pain in the butt, but I've never felt blocked
>>> by it. What has taken so long on pool/DBCP is that it is just Mark and I
>>> really digging into the code and we are both busy with other stuff / have
>>> limited time to work on it. Like some other components, the code is also
>>> kind of specialized and the documentation is not the best, making it harder
>>> for others to get involved. Collections went nowhere for a couple of years
>>> because no one stepped up to drive it. Thankfully Thomas did recently and
>>> we got a 4.0 beta. The best thing anyone can do to get a real 4.0 out is
>>> start actually coding on it.
>>>
>>> I honestly think we are making excuses in this thread - the real problem
>>> is dwindling component communities. We need to decide which ones to ale
>>> dormant and make it easier for people to get involved in the active ones.
>>>
>> S/ale/make (love that iPhone :)
>>
>>>
>>> On Sun, Oct 6, 2013 at 2:57 PM, Phil Steitz <ph...@gmail.com>
>>>>>> wrote:
>>>>>> On 10/6/13 11:45 AM, James Carman wrote:
>>>>>> Collections 4.x, nuff said
>>>>>>
>>>>> Huh? Didn't we release a beta? We could say the same thing about
>>>>> math 4.0, pool/dbcp 2.0, etc. These things are in progress. They
>>>>> will get released. There is activity. I don't get the big problem
>>>>> here.
>>>>>
>>>>> Phil
>>>>>
>>>>>>
>>>>>> On Sun, Oct 6, 2013 at 2:42 PM, Adrian Crum
>>>>>> <ad...@sandglass-software.com>>
>>>>>> wrote:
>>>>>>
>>>>>>> I would like to know the metrics for that conclusion. I see plenty of
>>>>>>> discussions and commits, but I'm not seeing any languishing.
>>>>>>>
>>>>>>> Adrian Crum
>>>>>>> Sandglass Software
>>>>>>> www.sandglass-software.com
>>>>>>>
>>>>>>>
>>>>>>> On 10/6/2013 11:30 AM, James Carman wrote:
>>>>>>>> All,
>>>>>>>>
>>>>>>>> The Apache Commons project seems to be languishing as of late and we
>>>>>>>> need some rejuvenation. Perhaps we should try to define our mission
>>>>>>>> as a project. What are our goals? What do we want to accomplish?
>>>>>>>> Who are our users/customers? What non-functional qualities do we
>>>>>>>> want
>>>>>>>> our software to exhibit? How do we want to conduct ourselves? How
>>>>>>>> often do we want to do releases? What else?
>>>>>>>>
>>>>>>>> Sincerely,
>>>>>>>>
>>>>>>>> James
>>>>>>>>
>>>>>>>> ------------------------------**------------------------------**
>>>>>>>> ---------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>> ------------------------------**------------------------------**
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>> ------------------------------**------------------------------**
>>>>>> ---------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>
>>>>> ------------------------------**------------------------------**
>>>>> ---------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>> ------------------------------**------------------------------**
>> ---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [DISCUSS] Mission Statement for Commons...
Posted by Dave Brosius <db...@apache.org>.
Phil,
You definitely have a point, but nothing helps build a development
community than seeing releases go out.
"I want to be part of that"
If there's no idea if or even when another version of a library will go
out, especially one that's hasn't released in a while, it deflates
possible joiners.
Even if we *just* released generized versions of the existing versions
and nothing else, that would be really helpful, i think, in pulling in
more help.
--dave
On 10/06/2013 04:53 PM, Phil Steitz wrote:
>
>> On Oct 6, 2013, at 1:46 PM, Phil Steitz <ph...@gmail.com> wrote:
>>
>>
>>
>>> On Oct 6, 2013, at 12:00 PM, James Carman <ja...@carmanconsulting.com> wrote:
>>>
>>> The fact that it has taken so long before we got something out for
>>> Collections 4.x is just an embarrassment. How long has Java had
>>> generics? What could be causing us to be so slow to get releases out?
>> I may be in the minority here, but I think the real problem is too many components for too few "committed committers". The release process has always been a little bit of a pain in the butt, but I've never felt blocked by it. What has taken so long on pool/DBCP is that it is just Mark and I really digging into the code and we are both busy with other stuff / have limited time to work on it. Like some other components, the code is also kind of specialized and the documentation is not the best, making it harder for others to get involved. Collections went nowhere for a couple of years because no one stepped up to drive it. Thankfully Thomas did recently and we got a 4.0 beta. The best thing anyone can do to get a real 4.0 out is start actually coding on it.
>>
>> I honestly think we are making excuses in this thread - the real problem is dwindling component communities. We need to decide which ones to ale dormant and make it easier for people to get involved in the active ones.
> S/ale/make (love that iPhone :)
>>
>>>>> On Sun, Oct 6, 2013 at 2:57 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>> On 10/6/13 11:45 AM, James Carman wrote:
>>>>> Collections 4.x, nuff said
>>>> Huh? Didn't we release a beta? We could say the same thing about
>>>> math 4.0, pool/dbcp 2.0, etc. These things are in progress. They
>>>> will get released. There is activity. I don't get the big problem
>>>> here.
>>>>
>>>> Phil
>>>>>
>>>>> On Sun, Oct 6, 2013 at 2:42 PM, Adrian Crum
>>>>> <ad...@sandglass-software.com> wrote:
>>>>>> I would like to know the metrics for that conclusion. I see plenty of
>>>>>> discussions and commits, but I'm not seeing any languishing.
>>>>>>
>>>>>> Adrian Crum
>>>>>> Sandglass Software
>>>>>> www.sandglass-software.com
>>>>>>
>>>>>>
>>>>>>> On 10/6/2013 11:30 AM, James Carman wrote:
>>>>>>> All,
>>>>>>>
>>>>>>> The Apache Commons project seems to be languishing as of late and we
>>>>>>> need some rejuvenation. Perhaps we should try to define our mission
>>>>>>> as a project. What are our goals? What do we want to accomplish?
>>>>>>> Who are our users/customers? What non-functional qualities do we want
>>>>>>> our software to exhibit? How do we want to conduct ourselves? How
>>>>>>> often do we want to do releases? What else?
>>>>>>>
>>>>>>> Sincerely,
>>>>>>>
>>>>>>> James
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by Phil Steitz <ph...@gmail.com>.
> On Oct 6, 2013, at 1:46 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>
>
>> On Oct 6, 2013, at 12:00 PM, James Carman <ja...@carmanconsulting.com> wrote:
>>
>> The fact that it has taken so long before we got something out for
>> Collections 4.x is just an embarrassment. How long has Java had
>> generics? What could be causing us to be so slow to get releases out?
>
> I may be in the minority here, but I think the real problem is too many components for too few "committed committers". The release process has always been a little bit of a pain in the butt, but I've never felt blocked by it. What has taken so long on pool/DBCP is that it is just Mark and I really digging into the code and we are both busy with other stuff / have limited time to work on it. Like some other components, the code is also kind of specialized and the documentation is not the best, making it harder for others to get involved. Collections went nowhere for a couple of years because no one stepped up to drive it. Thankfully Thomas did recently and we got a 4.0 beta. The best thing anyone can do to get a real 4.0 out is start actually coding on it.
>
> I honestly think we are making excuses in this thread - the real problem is dwindling component communities. We need to decide which ones to ale dormant and make it easier for people to get involved in the active ones.
S/ale/make (love that iPhone :)
>
>
>>>> On Sun, Oct 6, 2013 at 2:57 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>> On 10/6/13 11:45 AM, James Carman wrote:
>>>> Collections 4.x, nuff said
>>>
>>> Huh? Didn't we release a beta? We could say the same thing about
>>> math 4.0, pool/dbcp 2.0, etc. These things are in progress. They
>>> will get released. There is activity. I don't get the big problem
>>> here.
>>>
>>> Phil
>>>>
>>>>
>>>> On Sun, Oct 6, 2013 at 2:42 PM, Adrian Crum
>>>> <ad...@sandglass-software.com> wrote:
>>>>> I would like to know the metrics for that conclusion. I see plenty of
>>>>> discussions and commits, but I'm not seeing any languishing.
>>>>>
>>>>> Adrian Crum
>>>>> Sandglass Software
>>>>> www.sandglass-software.com
>>>>>
>>>>>
>>>>>> On 10/6/2013 11:30 AM, James Carman wrote:
>>>>>> All,
>>>>>>
>>>>>> The Apache Commons project seems to be languishing as of late and we
>>>>>> need some rejuvenation. Perhaps we should try to define our mission
>>>>>> as a project. What are our goals? What do we want to accomplish?
>>>>>> Who are our users/customers? What non-functional qualities do we want
>>>>>> our software to exhibit? How do we want to conduct ourselves? How
>>>>>> often do we want to do releases? What else?
>>>>>>
>>>>>> Sincerely,
>>>>>>
>>>>>> James
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by Phil Steitz <ph...@gmail.com>.
> On Oct 6, 2013, at 12:00 PM, James Carman <ja...@carmanconsulting.com> wrote:
>
> The fact that it has taken so long before we got something out for
> Collections 4.x is just an embarrassment. How long has Java had
> generics? What could be causing us to be so slow to get releases out?
I may be in the minority here, but I think the real problem is too many components for too few "committed committers". The release process has always been a little bit of a pain in the butt, but I've never felt blocked by it. What has taken so long on pool/DBCP is that it is just Mark and I really digging into the code and we are both busy with other stuff / have limited time to work on it. Like some other components, the code is also kind of specialized and the documentation is not the best, making it harder for others to get involved. Collections went nowhere for a couple of years because no one stepped up to drive it. Thankfully Thomas did recently and we got a 4.0 beta. The best thing anyone can do to get a real 4.0 out is start actually coding on it.
I honestly think we are making excuses in this thread - the real problem is dwindling component communities. We need to decide which ones to ale dormant and make it easier for people to get involved in the active ones.
>> On Sun, Oct 6, 2013 at 2:57 PM, Phil Steitz <ph...@gmail.com> wrote:
>>> On 10/6/13 11:45 AM, James Carman wrote:
>>> Collections 4.x, nuff said
>>
>> Huh? Didn't we release a beta? We could say the same thing about
>> math 4.0, pool/dbcp 2.0, etc. These things are in progress. They
>> will get released. There is activity. I don't get the big problem
>> here.
>>
>> Phil
>>>
>>>
>>> On Sun, Oct 6, 2013 at 2:42 PM, Adrian Crum
>>> <ad...@sandglass-software.com> wrote:
>>>> I would like to know the metrics for that conclusion. I see plenty of
>>>> discussions and commits, but I'm not seeing any languishing.
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>>
>>>>> On 10/6/2013 11:30 AM, James Carman wrote:
>>>>> All,
>>>>>
>>>>> The Apache Commons project seems to be languishing as of late and we
>>>>> need some rejuvenation. Perhaps we should try to define our mission
>>>>> as a project. What are our goals? What do we want to accomplish?
>>>>> Who are our users/customers? What non-functional qualities do we want
>>>>> our software to exhibit? How do we want to conduct ourselves? How
>>>>> often do we want to do releases? What else?
>>>>>
>>>>> Sincerely,
>>>>>
>>>>> James
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by James Carman <ja...@carmanconsulting.com>.
The fact that it has taken so long before we got something out for
Collections 4.x is just an embarrassment. How long has Java had
generics? What could be causing us to be so slow to get releases out?
On Sun, Oct 6, 2013 at 2:57 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 10/6/13 11:45 AM, James Carman wrote:
>> Collections 4.x, nuff said
>
> Huh? Didn't we release a beta? We could say the same thing about
> math 4.0, pool/dbcp 2.0, etc. These things are in progress. They
> will get released. There is activity. I don't get the big problem
> here.
>
> Phil
>>
>>
>> On Sun, Oct 6, 2013 at 2:42 PM, Adrian Crum
>> <ad...@sandglass-software.com> wrote:
>>> I would like to know the metrics for that conclusion. I see plenty of
>>> discussions and commits, but I'm not seeing any languishing.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>>
>>> On 10/6/2013 11:30 AM, James Carman wrote:
>>>> All,
>>>>
>>>> The Apache Commons project seems to be languishing as of late and we
>>>> need some rejuvenation. Perhaps we should try to define our mission
>>>> as a project. What are our goals? What do we want to accomplish?
>>>> Who are our users/customers? What non-functional qualities do we want
>>>> our software to exhibit? How do we want to conduct ourselves? How
>>>> often do we want to do releases? What else?
>>>>
>>>> Sincerely,
>>>>
>>>> James
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by Christian Grobmeier <gr...@gmail.com>.
On 6 Oct 2013, at 20:57, Phil Steitz wrote:
> On 10/6/13 11:45 AM, James Carman wrote:
>> Collections 4.x, nuff said
>
> Huh? Didn't we release a beta? We could say the same thing about
> math 4.0, pool/dbcp 2.0, etc. These things are in progress. They
> will get released. There is activity. I don't get the big problem
> here.
When did we start with working on pool/dbcp 2.0?
Seriously we are not really "releasing early, releasing often".
> Phil
>>
>>
>> On Sun, Oct 6, 2013 at 2:42 PM, Adrian Crum
>> <ad...@sandglass-software.com> wrote:
>>> I would like to know the metrics for that conclusion. I see plenty of
>>> discussions and commits, but I'm not seeing any languishing.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>>
>>> On 10/6/2013 11:30 AM, James Carman wrote:
>>>> All,
>>>>
>>>> The Apache Commons project seems to be languishing as of late and we
>>>> need some rejuvenation. Perhaps we should try to define our mission
>>>> as a project. What are our goals? What do we want to accomplish?
>>>> Who are our users/customers? What non-functional qualities do we want
>>>> our software to exhibit? How do we want to conduct ourselves? How
>>>> often do we want to do releases? What else?
>>>>
>>>> Sincerely,
>>>>
>>>> James
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by Phil Steitz <ph...@gmail.com>.
On 10/6/13 11:45 AM, James Carman wrote:
> Collections 4.x, nuff said
Huh? Didn't we release a beta? We could say the same thing about
math 4.0, pool/dbcp 2.0, etc. These things are in progress. They
will get released. There is activity. I don't get the big problem
here.
Phil
>
>
> On Sun, Oct 6, 2013 at 2:42 PM, Adrian Crum
> <ad...@sandglass-software.com> wrote:
>> I would like to know the metrics for that conclusion. I see plenty of
>> discussions and commits, but I'm not seeing any languishing.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>>
>> On 10/6/2013 11:30 AM, James Carman wrote:
>>> All,
>>>
>>> The Apache Commons project seems to be languishing as of late and we
>>> need some rejuvenation. Perhaps we should try to define our mission
>>> as a project. What are our goals? What do we want to accomplish?
>>> Who are our users/customers? What non-functional qualities do we want
>>> our software to exhibit? How do we want to conduct ourselves? How
>>> often do we want to do releases? What else?
>>>
>>> Sincerely,
>>>
>>> James
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by James Carman <ja...@carmanconsulting.com>.
Collections 4.x, nuff said
On Sun, Oct 6, 2013 at 2:42 PM, Adrian Crum
<ad...@sandglass-software.com> wrote:
> I would like to know the metrics for that conclusion. I see plenty of
> discussions and commits, but I'm not seeing any languishing.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
>
> On 10/6/2013 11:30 AM, James Carman wrote:
>>
>> All,
>>
>> The Apache Commons project seems to be languishing as of late and we
>> need some rejuvenation. Perhaps we should try to define our mission
>> as a project. What are our goals? What do we want to accomplish?
>> Who are our users/customers? What non-functional qualities do we want
>> our software to exhibit? How do we want to conduct ourselves? How
>> often do we want to do releases? What else?
>>
>> Sincerely,
>>
>> James
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
Posted by Adrian Crum <ad...@sandglass-software.com>.
I would like to know the metrics for that conclusion. I see plenty of
discussions and commits, but I'm not seeing any languishing.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 10/6/2013 11:30 AM, James Carman wrote:
> All,
>
> The Apache Commons project seems to be languishing as of late and we
> need some rejuvenation. Perhaps we should try to define our mission
> as a project. What are our goals? What do we want to accomplish?
> Who are our users/customers? What non-functional qualities do we want
> our software to exhibit? How do we want to conduct ourselves? How
> often do we want to do releases? What else?
>
> Sincerely,
>
> James
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org