[DISCUSS] Mission Statement for Commons...

classic Classic list List threaded Threaded
68 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Mission Statement for Commons...

sebb-2-2
On 6 October 2013 21:46, Phil Steitz <[hidden email]> wrote:
>
>
>> On Oct 6, 2013, at 12:00 PM, James Carman <[hidden email]> 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 <[hidden email]> 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
>>>> <[hidden email]> 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: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Mission Statement for Commons...

Dave Brosius-2
In reply to this post by Phil Steitz
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 <[hidden email]> wrote:
>>
>>
>>
>>> On Oct 6, 2013, at 12:00 PM, James Carman <[hidden email]> 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 <[hidden email]> 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
>>>>> <[hidden email]> 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: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Mission Statement for Commons...

Romain Manni-Bucau
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" <[hidden email]> 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 <[hidden email]> wrote:
>>>
>>>
>>>
>>>  On Oct 6, 2013, at 12:00 PM, James Carman <[hidden email]>
>>>> 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 <[hidden email]>
>>>>>> 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
>>>>>> <adrian.crum@sandglass-**software.com<[hidden email]>>
>>>>>> 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<[hidden email]>
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>> ------------------------------**------------------------------**
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>> ------------------------------**------------------------------**
>>>>>> ---------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>
>>>>> ------------------------------**------------------------------**
>>>>> ---------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>  ------------------------------**------------------------------**
>> ---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Mission Statement for Commons...

Phil Steitz


> On Oct 6, 2013, at 2:28 PM, Romain Manni-Bucau <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> wrote:
>>>>
>>>>
>>>>
>>>> On Oct 6, 2013, at 12:00 PM, James Carman <[hidden email]>
>>>>> 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 <[hidden email]>
>>>>>>> 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
>>>>>>> <adrian.crum@sandglass-**software.com<[hidden email]>>
>>>>>>> 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<[hidden email]>
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>> ------------------------------**------------------------------**
>>>>>>>> ---------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>> ------------------------------**------------------------------**
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>> ------------------------------**------------------------------**
>>>>>> ---------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
>>>>>> For additional commands, e-mail: [hidden email]
>>>>> ------------------------------**------------------------------**
>>>>> ---------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
>>> For additional commands, e-mail: [hidden email]
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Mission Statement for Commons...

Olivier Lamy
In reply to this post by Phil Steitz
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 <[hidden email]> wrote:

>
>
>> On Oct 6, 2013, at 12:00 PM, James Carman <[hidden email]> 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 <[hidden email]> 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
>>>> <[hidden email]> 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: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Mission Statement for Commons...

Luc Maisonobe
In reply to this post by Christian Grobmeier
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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
> ---
> http://www.grobmeier.de
> @grobmeier
> GPG: 0xA5CC90DB
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Mission Statement for Commons...

jochen-2
In reply to this post by James Carman
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 <[hidden email]>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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
"That's what prayers are ... it's frightened people trying to make friends
with the bully!"

Terry Pratchett. The Last Hero
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Mission Statement for Commons...

Jean-Louis MONTEIRO-2
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 <[hidden email]>

> 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 <[hidden email]
> >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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> "That's what prayers are ... it's frightened people trying to make friends
> with the bully!"
>
> Terry Pratchett. The Last Hero
>



--
Jean-Louis
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Mission Statement for Commons...

Romain Manni-Bucau
+1
Le 7 oct. 2013 12:58, "Jean-Louis MONTEIRO" <[hidden email]> 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 <[hidden email]>
>
> > 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 <[hidden email]
> > >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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> >
> > --
> > "That's what prayers are ... it's frightened people trying to make
> friends
> > with the bully!"
> >
> > Terry Pratchett. The Last Hero
> >
>
>
>
> --
> Jean-Louis
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Mission Statement for Commons...

Christian Grobmeier
In reply to this post by Jean-Louis MONTEIRO-2
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 <[hidden email]>
>
>> 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
>> <[hidden email]
>>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>> --
>> "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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Mission Statement for Commons...

jochen-2
On Mon, Oct 7, 2013 at 1:42 PM, Christian Grobmeier <[hidden email]>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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Mission Statement for Commons...

Christian Grobmeier
On 7 Oct 2013, at 13:58, Jochen Wiedmann wrote:

> On Mon, Oct 7, 2013 at 1:42 PM, Christian Grobmeier
> <[hidden email]>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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Mission Statement for Commons...

jochen-2
On Mon, Oct 7, 2013 at 2:05 PM, Christian Grobmeier <[hidden email]>wrote:

> On 7 Oct 2013, at 13:58, Jochen Wiedmann wrote:
>
>  On Mon, Oct 7, 2013 at 1:42 PM, Christian Grobmeier <[hidden email]
>> >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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Mission Statement for Commons...

James Carman
In reply to this post by Christian Grobmeier
On Sun, Oct 6, 2013 at 3:44 PM, Christian Grobmeier <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Mission Statement for Commons...

Benedikt Ritter-4
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 <[hidden email]>

> On Sun, Oct 6, 2013 at 3:44 PM, Christian Grobmeier <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Mission Statement for Commons...

Ate Douma
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 <[hidden email]>
>
>> On Sun, Oct 6, 2013 at 3:44 PM, Christian Grobmeier <[hidden email]>
>> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Mission Statement for Commons...

Thomas Neidhart
In reply to this post by Christian Grobmeier
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

Emmanuel Bourg-3
In reply to this post by Benedikt Ritter-4
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

Stefan Bodewig
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

Torsten Curdt-3
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
1234