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" <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 > >
