On Thu, Nov 11, 2010 at 06:49:26PM +0100, Macieira Thiago (Nokia-MS-Qt/Oslo) wrote: > Em Quinta-feira, 11 de Novembro de 2010, às 17:56:25, Oswald Buddenhagen > escreveu: > > you cannot push an untouched merge to the integration branch without > > flushing the queue (i.e., waiting until the current integration run is > > done) and blocking further integrations until you are done. > > that's simply too disruptive for the regular operation of the system. > > Indeed. But that's exactly what we're proposing. > not me. i'm proposing something better. ;)
> It's what we have now and nothing changes. > well, in fact, what we have now will merge the merge into the meanwhile progressed mainline branch (*), i.e., it produces "merge spam" - exactly the thing we don't want. but you'd have to do exactly that if you wanted a non-disruptive non-replaying merge process. (*) well, the current CI system will also create an additional merge if mainline did not progress, but that's besides the point. > > if we are good players we'll publish all infrastructure anyway, so > > everyone can run his own instance. > > Instance of what? > of the ci system of course. > > > I also don't see the need for secret branches at all. > > > > as if something like the s60 port could never happen again. > > > Well, that's Nokia's problem, not the Qt Project's problem. > i'd be a bit more pragmatic about that. ;) > The public infrastructure is for public stuff. If someone wants to keep a > private branch, they can do that. > They don't get to use our infrastructure though. > not the hardware, but we (nokia) definitely should publish all software and configuration we create in the process. that's a moot point if the tools are developed with active cooperation from the external community in the first place. _______________________________________________ Opengov mailing list Opengov@qt-labs.org http://lists.qt-labs.org/listinfo/opengov
