commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: [DISCUSS] Mission Statement for Commons...
Date Sun, 06 Oct 2013 21:28:23 GMT
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" <dbrosius@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.steitz@gmail.com> wrote:
>>>
>>>
>>>
>>>  On Oct 6, 2013, at 12:00 PM, James Carman <james@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.steitz@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.crum@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-unsubscribe@commons.apache.org>
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>> ------------------------------**------------------------------**
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<dev-unsubscribe@commons.apache.org>
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>> ------------------------------**------------------------------**
>>>>>> ---------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<dev-unsubscribe@commons.apache.org>
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>
>>>>> ------------------------------**------------------------------**
>>>>> ---------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<dev-unsubscribe@commons.apache.org>
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<dev-unsubscribe@commons.apache.org>
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>  ------------------------------**------------------------------**
>> ---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<dev-unsubscribe@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<dev-unsubscribe@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message