I don't think I would blame this on the process so much as the toolchain... it seems like the same inputs generate radically different outputs on different systems and development tools. Some of this is related to IDEs... in GNU C projects the IDE and the build system are basically one and the same. People hack with text editors and build with the same build system used for release. Here we have people hacking and building with an IDE, then only using the release build system at the end (and occasionally grudgingly).
I am surprised the official build itself is broken, and wonder why we are back at this stage again. For a while there was consensus that broken build was unacceptable... if you break it, you fix it, and (even better) you just never commit something that breaks it. Is this a result of people not running tests, or everyone running *different* sets of tests (some people run online tests, others don't, etc). We are working on getting our continuous build server set up with *all* the online tests activated, so perhaps we can resume a cruisecontrol system and ask people to not leave their desks until their commits are tested and passed? P On 10-Aug-06, at 12:30 PM, Adrian Custer wrote: > Hey Ian, > > My eclipse is pretty unhappy with all the changes you just made. It > wants to move my classes around, can't find any of the classes it > needs > and acts generally sick. How sure are you about what you did? > > Hey all, > > Is there a policy on commits this late in the release process? Is > everyone really still allowed to hack away, guessing their way > towards a > resolution? 2.2.0 needs to go out and the general frenzy of > commits/broken builds has no buisness in a well managed project. At > this > point in most projects I've ever worked in, *every* commit needs to go > through a code review. > > Richard, it may be up to you to tame this unruly mess. It's probably > more than you signed up for but there's blood in the water... > > --adrian > > > > On Thu, 2006-08-10 at 13:46 -0400, Ian Turton wrote: >> On 8/10/06, Ian Turton <[EMAIL PROTECTED]> wrote: >>> I think I've found the problem - the messages.properties file wasn't >>> getting included in the jar file. It worked fine on my machine since >>> I'm using eclipse to manage my classpath. Can you try again and see >>> what happens at your end. And if someone who knows about maven2 can >>> check I've done the include right that would be great. >>> >> >> OK I've made another change and it seems to put everything in the >> right place now. though possibly the data should move to demo now. >> >> The only way I could build this release was to turn off testing which >> seems like a bad thing for a release. >> >> Ian >> > > > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
