> On Oct 6, 2013, at 2:28 PM, Romain Manni-Bucau <rmannibu...@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" <dbros...@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 <phil.ste...@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 <phil.ste...@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
>>>>>>> <adrian.crum@sandglass-**software.com<adrian.c...@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<dev-unsubscr...@commons.apache.org>
>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>> ------------------------------**------------------------------**
>>>>>>>> ---------
>>>>>>>> To unsubscribe, e-mail: 
>>>>>>>> dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org>
>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>> ------------------------------**------------------------------**
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: 
>>>>>>> dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org>
>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>> 
>>>>>> ------------------------------**------------------------------**
>>>>>> ---------
>>>>>> To unsubscribe, e-mail: 
>>>>>> dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org>
>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>> ------------------------------**------------------------------**
>>>>> ---------
>>>>> To unsubscribe, e-mail: 
>>>>> dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org>
>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>> 
>>>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: 
>>> dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org>
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: 
>> dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org>
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 

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

Reply via email to