> 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
