Am 13.10.2013 22:08, schrieb Benedikt Ritter: > 2013/10/13 Oliver Heger <oliver.he...@oliver-heger.de> > >> Am 11.10.2013 22:55, schrieb Benedikt Ritter: >>> 2013/10/11 Oliver Heger <oliver.he...@oliver-heger.de> >>> >>>> Am 11.10.2013 22:01, schrieb Benedikt Ritter: >>>>> 2013/10/11 Oliver Heger <oliver.he...@oliver-heger.de> >>>>> >>>>>> Am 11.10.2013 02:10, schrieb Phil Steitz: >>>>>>> >>>>>>> >>>>>>>> On Oct 10, 2013, at 4:41 PM, Olivier Lamy <ol...@apache.org> wrote: >>>>>>>> >>>>>>>> Even I like git and use it daily, I will vote +0,5. >>>>>>>> >>>>>>>> Why other apache projects need to have their own commons-csv >>>>>>>> repackaged release? why tomcat need to use a svn:external on dbcp >>>>>>>> instead of a released version? why servicemix need to repackage all >>>>>>>> commons jar to have proper osgi bundles? >>>>>>>> >>>>>>>> I simply believe moving to git won't fix those problems about the >> too >>>>>>>> complicated release process which scare folks here to try releasing >> a >>>>>>>> component!! >>>>>>>> So no release happen at the end.... >>>>>>>> >>>>>>> I agree that the release process is certainly a problem; but the big >>>>>> problem IMO is just too many components for too few really active >>>>>> committers. Once we actually have something ready to release, we have >>>>>> generally been able to fumble our way through the process. The >> problem >>>> is >>>>>> getting there. >>>>>>> >>>>>>> I think the best thing we can do is focus on getting some things >> ready >>>>>> for release. I will help on pool, DBCP, math. I won't rob Mark of >> the >>>>>> oppty to rm pool2, but will help ;). All are welcome to join the fun >>>>>> cleaning up the docs and other loose ends on that and then dbcp2. >>>>>>> >>>>>>> Who wants to step up to drive some other things to release? >>>>>> I plan to prepare a release of BeanUtils soon. >>>>>> >>>>> >>>>> Good to hear. There is a lot to do. I started generification a while >>>> back. >>>>> If you like you can join #asfcommons and we can have a talk about BU. >>>> >>>> I did not look into the open issues so far. I would rather take a more >>>> minimalistic approach, i.e. pushing out version 1.9 with what is >>>> currently there and then put more energy in BeanUtils2. >>>> >>>> >>> I looked through most issues. There were three categories: >>> - issues I was unable to fix >>> - issues I was unable to reproduce >>> - issues I was unable to understand because they were written in some >>> strange asian-english mixture >>> >>> But we can have another iteration and talk about the things. >>> Generics can be removed if you want to do a minimal release. >> It is certainly annoying to have all these generics warnings in the >> code, especially if there are already some classes that have been >> adapted. Do you remember roughly how many classes you did rework when >> you started with generification? >> > > None, I just changes the language level. I wanted to review all open issues > before starting with the generification, because the changes all over the > place will make appling patches very difficult. I think it was Sebb who > started, before I told him my intention. > > >> >> I guess I will start an attempt to generify some classes and see how far >> this gets and how easy or complicated it is. Then we can decide whether >> we use generics or not. > > > IMHO another release of BU1 should have generics. If it is to difficult we > should better invest the time to work on BU2.
Yes, I also prefer having generics. However, there is a dependency of [configuration] 2.0 and a new feature of BU, so I really need to push out a release. Oliver > > >> >> Oliver >> >>> >>> BU2 is a hole different story. It's more like a prototype. But I'd love >> to >>> start work on it again. >>> >>> >>>> Oliver >>>> >>>>> >>>>> Benedikt >>>>> >>>>> >>>>>> >>>>>> Oliver >>>>>> >>>>>>> >>>>>>> Phil >>>>>>>> >>>>>>>>> On 11 October 2013 01:50, James Carman <ja...@carmanconsulting.com >>> >>>>>> wrote: >>>>>>>>> All, >>>>>>>>> >>>>>>>>> We have had some great discussions about moving our SCM to Git. I >>>>>>>>> think it's time to put it to a vote. So, here we go: >>>>>>>>> >>>>>>>>> +1 - yes, move to Git >>>>>>>>> -1 - no, do not move to Git >>>>>>>>> >>>>>>>>> The vote will be left open for 72 hours. Go! >>>>>>>>> >>>>>>>>> >> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Olivier Lamy >>>>>>>> Ecetera: http://ecetera.com.au >>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>>>>>> >>>>>>>> >> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: 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 >>>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: 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 >>>> >>>> >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: 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
