lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <rcm...@gmail.com>
Subject Re: Brainstorming on Improving the Release Process
Date Wed, 30 Mar 2011 13:19:55 GMT
On Wed, Mar 30, 2011 at 8:22 AM, Grant Ingersoll <gsingers@apache.org> 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.
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.

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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message