Hi Henri, I agree with that policy, that's why I pushed the digester-05-RC1 so quickly (also because we've overlooked this problems since 2008 :P), BW what really blocked the release was the fact that I didn't discuss which JIRA issues should had been fixed before pushing a new release. So, taking advantage of the time, since discovery is very small in size, compared to other components, I thought it would have been nice having a fresh new clean codebase. Do you have more suggestion for me before pushing a new RC2? I would more than glad to follow a generally approved policy. Thanks in advance, have a nice day! Simo
http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Apr 5, 2011 at 9:52 AM, 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. > > 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
