On Wed, Mar 30, 2011 at 8:22 AM, Grant Ingersoll <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
