Re: [PATCH OSSTEST+XEN 0/1+1] Switching to one qemu tree per qemu version (trad vs upstream)

[Ian Campbell <ian.campbell@citrix.com>]

On Thu, 2015-09-17 at 11:23 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST+XEN 0/1+1] Switching to one qemu tree per qemu version (trad vs upstream)"):
> > I believe the plan for deployment should be:
> > 
> >  * Today we can already just remove the old staging/qemu-xen-* trees, they
> >    are unused (apart from being manually pushed to along with the staging
> >    trees, I think).
> 
> Yes.  (it needs some consequential changes to my ad-hoc scripts but
> that's fine.)

Which reminds me: there will no doubt be some knock on effects on the
release check list both for 4.7 and for existing stable branches which
pickup the Config.mk change.

> 
> >  * Push the osstest patch (possibly consider a force push? An osstest
> >    flight doesn't actually exercise this and it would make coordination
> >    with the next step easier...)
> 
> A force push would seem fine to me.
> 
> >  * ASAP after the osstest patch reaches production push the patch to
> >    xen.git#staging. This will cause the xen-unstable builds to use the
> > new
> >    output gate. Until this is done unstable builds will continue using
> > the
> >    old master push gate, which is not updated after the osstest update
> >    (only stable branches are), this isn't a big deal but obviously a
> >    smaller window would be better.
> 
> Right.
> 
> >  * At this point we could remove the old staging/qemu-upstream-* trees,
> >    they are not referenced by anything.
> 
> Promptly removing things that are unreferenced and not updated would
> be a good idea :-).

Right. My concern would be people with trees cloned from it, I suppose they
will get the git equivalent of a 404 and can update.

> 
> >  * At our leisure backport the xen.git change to stable branches,
> > probably
> >    back as far as 4.2 (when qemu-xen was introduced).
> >  * Do stable releases of each of the above.
> 
> This will take quite some time.

Yes, I don't envisage this stage happening quickly. More "in the natural
course of things".

> 
> >  * Drop (one by one or all at once) the push to the legacy stable
> > branches
> >    from osstest as stable releases are made referencing the new trees.
> 
> I think it would be sensible to do this all at once and to expect to
> do it perhaps 12 months from when we start.

Ack.

> >  * Consider hiding (or removing) the old output trees from xenbits as
> > well.
> 
> Hiding them would be a good idea.  I wonder if that's possible.

Sadly not in the mode which we use gitweb in which is to effectively do
"find $root" and export everything, with no blacklist support.

It is possible to switch to a mode which is default deny with an explicit
whitelist, which would involve some faff for each tree we create. I'm not
sure if it is worth it.

NB in that mode it should be possible to have repos which are present (i.e.
can be cloned) but not listed on the gitweb index page, and which still
have their own subpage if you know where to look.

I've deployed gitolite on my own VPS not so long ago, perhaps we should
look at this, as a medium term goal, it would also make it easier to give
people trees without ssh accounts and to do access control on various
shared trees etc.

Ian.