On 4/5/11 10:14 AM, Gary Gregory wrote: > On Apr 5, 2011, at 3:53, Henri Yandell <flame...@gmail.com> wrote: > >> On Tue, Apr 5, 2011 at 12:40 AM, <luc.maison...@free.fr> wrote: >>> ----- "Henri Yandell" <flame...@gmail.com> a écrit : >>> >>>> On Mon, Apr 4, 2011 at 5:13 AM, Gary Gregory <garydgreg...@gmail.com> >>>> wrote: >>>>> On Apr 4, 2011, at 1:45, Simone Tripodi <simonetrip...@apache.org> >>>> wrote: >>>>>> Hi Gary! >>>>>> I honestly even thought about it, so sorry! :( Since Discovery >>>>>> activity has not been hight since 2008, I just thought adding the >>>>>> missing generics support and nothing more :( >>>>>> I don't think that should be a blocking issue since we've been >>>>>> "overlooked" them for a long time, BTW if we think the effort of >>>>>> fixing the checkstyle warnings can help the component health, I'll >>>>>> cancel this vote and rollout a new one as soon as I can. >>>>>> WDYT? Many thanks in advance for your feedbacks! >>>>>> Have a nice day, >>>>>> Simo >>>>> IMO a release should be a clean as possible. I also like the >>>> release >>>>> early release often pattern so you could fix it all next. I am not >>>>> sure what your plans are for further releases. If you are working >>>>> towards more releases toward a 1.0 then it's ok I suppose. >>>> I increasingly find that feels wrong. We're in the release >>>> early/release often business and trying to over-polish not only >>>> pushes >>>> the release back, but it also decreases the release often as there >>>> are >>>> less items to do. >>>> >>>> Somewhere in my gut I feel it might be worse than that. There's a >>>> "someone cares" level of quality to achieve, but minor imperfections >>>> can drive community. The bugs in our software are our recruitment >>>> drive, and getting rid of all of the low-hanging-fruit interferes >>>> with >>>> that. That seems insane if we put our business developer hats on, but >>>> you have to remember that what we do also seems insane. >>> I would never have thought about bugs as an incentive for newcomers. >>> >>> It does make sense. >>> >>>> My take away on these internal gastric rumblings has been: >>>> >>>> * If you are the only committer actively working on a project; and >>>> it's been that way for a while; then leave the warts. Focus on the >>>> important subjects and get releases out. >>>> * If you are newish to driving the project, fix the warnings. It's a >>>> good practice and gets you into the code more. >>>> * If there are lots of committers; fix some of the warnings. Lead by >>>> example but don't do all the work. >>> I think there is also another criterion: >>> >>> * if there is an overwhelming number of warnings, reduce it drastically >>> to a manageable number >>> >>> There are two reasons for this criterion. The first reason is that when you >>> have >>> hundreds or thousands of >>> javac/javadoc/eclipse/checkstyle/findbugs/clirr/Sebb >>> warnings, it is easy to miss an important one hidden by numerous minor ones. >>> The second reason is that when there are two many warnings, this may also >>> drive >>> wannabe committers away, either because they feel the current team is not >>> interested in quality fixes or because they are afraid by the amount of >>> work to >>> fix things. >> Agreed. It's not that fixing warnings are bad, it's that making them >> release blockers is an anti-pattern. >> >> The most painful thing btw is doing a new major version of a component >> - you get stuck in a "can't release" cycle. We need to solve that one, >> Lang 3.0 should have been pushing out monthly alphas (on apache.org >> and in Maven). >> >> Gary - that's my major advice for Commons Codec 2.0. Plan on an alpha >> release every month. Even pick the recurring day. Shove it through and >> keep it fast. Get the alphas on the Maven repos. Don't allow things to >> block the monthly release beyond Legal and badly fubar. >> > I like it. Do alphas go through the same vote process? Yes, anything we release requires a VOTE.
Phil > Gary > >> Hen >> >> --------------------------------------------------------------------- >> 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
