lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: Brainstorming on Improving the Release Process
Date Wed, 30 Mar 2011 16:00:12 GMT

On Mar 30, 2011, at 9:19 AM, Robert Muir wrote:

> On Wed, Mar 30, 2011 at 8:22 AM, Grant Ingersoll <> wrote:
>> (Long post, please bear with me and please read!)
>> Now that we have the release done (I'm working through the publication process now),
I want to start the process of thinking about how we can improve the release process.  As
I see it, building the artifacts and checking the legal items are now almost completely automated
and testable at earlier stages in the game.
> Thanks for writing this up. Here is my major beef with 2 concrete suggestions:
> It seems the current process is that we all develop and develop and at
> some point we agree we want to try to release. At this point its the
> RM's job to "polish a turd", and no serious community participation
> takes place until an RC is actually produced: so its a chicken-and-egg
> thing, perhaps with the RM even declaring publicly 'i dont expect this
> to actually pass, i'm just building this to make you guys look at it'.
> I think its probably hard/impossible to force people to review this
> stuff before an RC, for some reason a VOTE seems to be the only thing
> for people to take it seriously.
> But what we can do is ask ourselves, how did the codebase become a
> turd in the first place? Because at one point we released off the code
> and the packaging was correct, there weren't javadocs warnings, and
> there weren't licensing issues, etc.
> So I think an important step would be to try to make more of this
> "continuous", in other words, we did all the work to fix up the
> codebase to make it releasable, lets implement things to enforce it
> stays this way. It seems we did this for some things (e.g. code
> correctness with the unit tests and licensing with the license
> checker) but there is more to do.
> A. implement the hudson-patch capability to vote -1 on patches that
> break things as soon as they go on the JIRA issues. this is really
> early feedback and I think will go a long way.

+1.  I asked on builds@a.o if there was any "standard" way of doing this, or if there is a
place someone can point me at to get this going.

> B. increase the scope of our 'ant test'/hudson runs to check more
> things. For example, it would be nice if they failed on javadocs
> warnings. Its insane if you think about it: we go to a ton of effort
> to implement really cruel and picky unit tests to verify the
> correctness of our code, but you can almost break the packaging and
> documentation completely and the build still passes.

+1 on failing on javadocs.

Also, what about code coverage?  We run all this Clover stuff, but how do we incorporate that
into our dev. cycle?

> Anyway, we spend a lot of time on trying to make our code correct, but
> our build is a bit messy. I know if we look at the time we spend on
> search performance and correctness, and applied even 1% of this effort
> to our build system to make it fast, picky, and and cleaner, that we
> would be in much better shape as a development team, with a faster
> compile/test/debug cycle to boot... I think there is a lot of
> low-hanging fruit here, and I think this thread has encouraged me to
> revisit the build and try to straighten some of this out.

Yeah, our build is a bit messy, lots of recursion.  I'm still not totally happy w/ how license
checking is hooked in.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message