Hi Dan, I never found the time to answer your interesting post, I hope you are still interested enough to read this now. :-)
Dan Kegel wrote: > But thorough automated testing can help by > a) pointing out regressions early so they can be fixed before they > infect the trunk, and > b) rubbing the noses of those who committed the regressions in their mess > closer to the time they did it; that way they get the message better that > they might need to improve their quality processes. I totally agree here, but at least now I don't agree to the way how your team has "implemented" that idea: > For instance, yesterday a new programmer on Chromium who had just gotten > his change to pass our automated voluntary presubmit smoke test (yay) > made a tiny change and then checked in without testing (boo). > The trunk's massive automated testing caught it quickly and dramatically, > and the IRC channel filled up with chatter about the programmer. > He heard about this, came onto IRC, apologized profusely, and > promised to never make that mistake again. All this within 20 > minutes of him making the mistake. How quickly do OOo > programmers get feedback about easy regressions checked into CWSs? You can have the same testing that you applied to the trunk on any other copy of the code. Thanks to a DSCM, you can even have the code from the trunk revision - but in another repository! The benefit of doing this is that you can "rub noses early" without bringing further progression in the trunk to halt until the bug is fixed. A possible implementation of this model for OOo would be to pull from all outgoing CWS repositories into a testing repository, build the stuff and test it. This way you get the same fast response to regressions as in your build model, but without the negative side effects. We once had immediate committing to the master/trunk and it didn't work well for us. Quite too often the master was in an unusable state and many developers lost time because of that. Admittedly we wouldn't get the response *that* far - due to the size of our build and the nature of our tests it usually takes hours to build and dasy to test. But every journey starts with the first step. (And of course that wouldn't be different with the "commit to master" model.) I believe that faster code integration into the master/trunk is possible without the same horrible results that we had before we started to work with CWS. But I wouldn't jump to conclusions and opt for this faster integration before we have commonly thought it through and discovered that it should work for us. > Chromium doesn't have feature branches (= CWS's, I think). In future a CWS won't be a branch because our DSCM doesn't have them. A CWS is just a snapshot of the trunk when you start by cloning your local repository, continuously updated from the trunk as often as the developer likes it. > Features and bugfixes land immediately on the trunk. That sounds as if your "features" are quite small. A feature development that lasts for several weeks or even months is not doable without some tooling that allows to synchronize the local copy of the developer with the trunk. In future the "tooling" will be the DSCM itself (pull/merge is enough to keep the local copy in sync), until now branches have been the only way to implement something similar. > This subjects > them to massive automated testing. If even a single test fails, we > close the tree to new checkins until the change is reverted or fixed, > the test is suppressed due to flakiness, or a bug is filed and the test > marked as a known regression and tracked in our bug tracking system. As I wrote, this is nothing we want to have again. Sometimes fixing regressions can takes days, and stopping code integration into trunk/master for so long is inacceptable. But as I explained, I don't think that this is possible. We can find regressions as early as we want without compromising the master/trunk version. > This cuts down on regressions due to merge problems. Steady and frequent updates of the local DSCM copy serves the same purpose. Doing this with svn was impossible (as it took ages to update!), but with a DSCM this is just a matter of minutes. Um, followed by some hours of building. But fortunately there are nights to do that. :-) > While OOo's build process has surely improved over the years, it might > be worth looking at further simplifications. Oh, yes. And I'm very interested in that. But before we can do this, we have to do some home work: - adapt the current system to a DSCM based build process (as we want to switch soon) - make the current build system more modular, simpler and faster - separate our code base into several repositories - improve our build dependencies I hope that after getting this done we can think about new ways for our build system. > Chromium recently switched (mostly) to a cmake-like tool called gyp > so that the native build system for all platforms is generated > automatically from a single source, and is updated whenever you > sync new sources. This is working out very nicely. (I don't recall > why we couldn't use cmake instead of inventing our own -- > it could be as simple as the guy doing our build tools loves > python -- but at least gyp is open source; http://gyp.googlecode.com.) > This makes it easier to program on one platform without breaking the others. Thanks for the hint. I doubt that we can adapt this easily, but I hope that we can learn something from it. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[email protected]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
