lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Upayavira">
Subject Re: Brainstorming on Improving the Release Process
Date Thu, 31 Mar 2011 13:40:21 GMT

On Wed, 30 Mar 2011 12:00 -0400, "Grant Ingersoll" <>
> 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.

Are you willing to say more? I have a little time, and have done a lot
of work with Ant. Maybe I could help.

Enterprise Search Consultant at Sourcesense UK, 
Making Sense of Open Source

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

View raw message