[Pkg-xen-devel] Current status

[Guido Trotter]

Hi!

Ok, last message for this morning, I promise! ;)

I just wanted to make the point with all of you about the status of our
packages, what we've done and what we're missing! Since what we've done is
already in the changelog, let's focus on what we're missing!

1. Upgrade: how is the upgrade path from 2.0.6 in unstable? One probably should,
after upgrading xen, which should be painless, build new kernels for the domain
0 and for all the guests... So it's quite a manual process... Can we help it
somehow? (it seems we cannot, for now...) We should at least document this
prominently in debian/NEWS.Debian or something, though!

2. Kernels: ok, we cannot distribute them, at least for now... We should
probably prepare some piece of documentation to help people creating them as
simply as possible! Also sample .config files could help: at least for the
unprivileged domains most people could use our config as is, while for the
domain 0 I'd advice them to build it customizing it. We can help providing a
"minimal" Domain 0 config, that could be used adding what one needs (eg,
drivers, ecc) but with everything that's needed/recommended by xen (eg.
bridging, etc). Then we can also provide a "comprehensive" .config, copied from
the debian one, so that if someone is lazy/doesn't really want to compile a
kernel he can build one without changing anything and by just giving some
commands... Other ideas to help our users?

3. Networking: do we want to leave it like it is? Or debianize it somehow? Or at
least explain people how to debianize it? Maybe disable the default scripts?
(Probably interfering with a machine's network configuration, like xen by
default does, by adding a bridge device and heuristically chosing which
interfaces should be added to it, and which ip address should it have could
count as a serious policy violation... And people could be really angry if for
any reason the networking configuration of a machine they administer remotely
breaks because of this! On the other hand if we make it clear from the beginning
it's *their* responsibility we play safe and also avoid eventual issues if we
decide to risk, they file an RC bug against our package, and we have to remove
the feature, then we'll also have to explain it to the users for which it worked)

4. Dealing with the maintainership: Adam hasn't opposed our project, but he
hasn't endorsed it either... What should we do before uploading? At least one
more mail to Adam and to debian-devel I guess it's due, at least to invite adam
to join us, or to check our changes, or at least to say "whatever, I don't care,
go ahead"

5. /lib/tls so, it seems we decided to leave it alone, for now... Before
uploading we should at least document this prominently! Then trying to
coordinate with the glibc guys and maybe asking debian-policy if there is any
way we can do that without them tracking us down and burning our homes could be
nice! But I guess we can postpone it, for now...

Any comments/suggestions on these? Other things I'm missing and we would
need/like to address? 

Oh, I'm still a bit unsure about what exactly the "installer" that Yvette
mentioned in her "Of historical interest only [u]" mail[1] was, so I haven't
mentioned it... Can someone please illuminate me! Thanks! ;)

Guido

[1] http://lists.alioth.debian.org/pipermail/pkg-xen-devel/2006-February/000037.html