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