Excerpts from Thiago Macieira's message of Thu Jul 15 13:53:03 +0100 2010: > This is something that works quite well, so we're not willing to let it go. > All changes must be unit-tested before being accepted, period.
Agreed. > Now, what can be improved is the organisation of the staging areas. My own thoughts here, especially given your 'inside perspective' is that simply put, the concept of staging areas isn't working out too well, while it might have been a good idea. You seem to proceed onto the same train of thought that I discussed (and started implementing) once, as treating contributions as a queue managed by an automated system. The system I started working on actually used MRs from Gitorious: - Contributor creates a MR - System runs, pulls all MRs as branches - System merges a batch of MRs (rejecting the ones that don't cleanly apply) - System tests the new Qt - System then pushes the resulting merged branch up if all goes well The way I'd treat this is to run in batches of X contributions at a time. You can detect merge failures instantly (and reject them for the author to fix them). Build and test failures are a little more complex - the way I'd do this is to push the batch aside for the moment and deal with the rest of the 'fresh' contributions. Once all the other contributions are out of the way (and CI is idle, ideally), go back to the batches that fail, and run them one at a time, eliminating the ones that fail, and applying the others as per the above process. You could always leave this for manual intervention as well, but I'd argue that you want to automate as much of this as possible, because it's boring work, and if it fails, people are eventually going to get sick of fixing it, so those batches will just keep piling up. > The way out of that is to modularise and keep the code size down, like taking > QtWebKit out of Qt's build saves 40% of the build time or more. And to > parallelise the running of tests, which our QA people are already attempting > to do, with fun results like two tests fighting for focus... Yeah.. been there.. had fun with that. :) > (side-effect: more people working at odd hours or during weekends to avoid > getting batched up) I personally see this as a good thing. Keeping things to one set of office hours has the effect of kind of meaning there's nobody around to help direct new people *out* of those hours.. which isn't going to help foster hacker growth. ;) I know that at the end of the day, it's "just a job", but by helping engage new people - you end up making your own work easier, too. -- Robin Burchell http://rburchell.com _______________________________________________ Opengov mailing list [email protected] http://lists.qt-labs.org/listinfo/opengov
