On Wed, 30 Mar 2011 12:00 -0400, "Grant Ingersoll" <gsing...@apache.org> wrote: > > On Mar 30, 2011, at 9:19 AM, Robert Muir wrote: > > > On Wed, Mar 30, 2011 at 8:22 AM, Grant Ingersoll <gsing...@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. > > +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. Upayavira --- Enterprise Search Consultant at Sourcesense UK, Making Sense of Open Source --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
