Re: ioemu

[Christoph Egger <Christoph.Egger@amd.com>]

On Monday 01 September 2008 12:05:36 Ian Jackson wrote:
> Christoph Egger writes ("[Xen-devel] ioemu"):
> > is it possible to get ioemu-remote into mercurial?
>
> No.  Well, it would be possible, but it wouldn't be desirable.

Why not? Everyone here is used to use mercurial.
Also the testing environments are bound on it. See below.

> > When I packaged Xen 3.3.0 for NetBSD, I run into the problem that
> > the git tree could not checked against a checksum because
> > a) the download happens during the build phase.
> > b) the checksum check works against one file but not against a whole tree
> > The checksum phase happens right after the download of the
> > Xen 3.3.0 source tarball.
> > I think, Gentoo Linux has the same problem.
>
> I'm not sure I understand what checksum you're referring to here.  Is
> it part of the NetBSD ports system ?  What does the ports system
> expect ?

The checksum is part of the package in pkgsrc. It needs an URL where
to download the source archive. After the download, the archive is verified
against SHA1 and RMD160 checksums and against its size in bytes.

Gentoo has taken over this concept when it was founded. And it is still
doing so.

> > I worked around this by using the in-tree ioemu.
>
> How about using the official 3.3.0 tarball which contains a copy of
> ioemu-remote ?

It doesn't compile on BSD (and hasn't got the testing).

> > In this respect, I would like to know if the move to the new ioemu
> > can be done by updating the ioemu code in the mercurial tree by
> > taking over the sources from the ioemu-remote tree into mercural
> > tree.
>
> We won't be doing this.  The point of using git rather than hg is to
> much more easily manage the interactions and patch workflows between
> the various branches of qemu, of which ioemu-remote is just one.
>
> Dealing well with this kind of forked up trainwreck requires a lot of
> heavy lifting from the revision control system.  git can do this
> (despite the appalling user interface) and hg can't.

Our testing infrastructure is based on changeset numbers. From reading
the number you immediately know is this an old or new changeset and
you immediately know how many changesets are between two changesets.
This makes it easy in finding a changeset which introduced a bug by bisecting.

With git using hash numbers no longer works.
(Ever tried to remember on the hash number you worked on at last for
one hour?)

> > This would also allow to create snapshot packages from unstable
> > via hg archive -t tgz xen-snapshot.tar.gz in a half-automated way.
>
> I agree it is a shame that our official tarball isn't made entirely
> mechanically.  If you would care to contribute a script that
> reproduces the 3.3.0 tarball when dropped into the appropriate
> xen-3.3-testing changeset, and also does a sane thing in currently
> xen-unstable, we'll consider including it and using it next time.

So you are planning to also move the hypervisor to git in the middle/long run?

Christoph

-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy