[Xen-API] Xapi project repositories

[Jon Ludlam <jonathan.ludlam@xxxxxxxxxxxxx>]

Hi all,

In preparing for the 2.0 release, it's become increasingly obvious that
we really need to tidy up the xapi-project org on github. There are many
repositories that are in the org that aren't a part of the Xapi Project.
I started making a list, and realised that there are a few other
inconsistencies that we ought to clean up at the same time, for example,
many repositories are marked as forks of personal repos where that
relationship ought to be reversed.



First, there are some repositories that should just be deleted:

- opam
A fork of github.com/ocaml/opam. I don't know why we have this, it
doesn't appear to have any commits from us.

- opam-repository
Same as opam.

- xcp-fhs
This is unused by anyone, as far as I know.

- xen-unstable-mirror
Just a mirror of the xen project repository.

- xcp-storage-managers
An old fork. sm.git should be used instead.

- ocaml-sha
A fork of upstream, no additional changesets from us.

- ocaml-tar
A fork of upstream, no additional changesets from us

- ocaml-vhd
A fork of upstream, no additional changesets from us



Secondly, I believe some of the repositories should be transferred to
the 'xenserver' organisation, which I think probably needs approval, as
the xenserver org is not a part of the Linux Foundation. These are:

- filesystem-summarise
A tool to check for filesystem changes. Useful on XenServer for
detecting when changes have been made to configuration files and so on.
Not useful for general installations of the xapi project.

- jiralib
An old python library for talking to jira. Superseded by jira-python
package.

- mirrortest
A test repository for checking Citrix's internal mirrors of the github
repositories.

- PRDup
'Pull Request Duplicator', a tool for helping to backport pull requests
to different branches.

- pull-request-manager
Uses Citrix's internal build system to test pull requests - no longer used.

- xs-pull-request-build-scripts
Replacement for pull-request-manager - uses Citrix's internal build
system to test pull requests, this time using jenkins.

- xen-api-libs-specs
Spec files used for building a lot of the xapi-project components for
XenServer. There is large overlap with github.com/xenserver/buildroot -
these should probably merge (or become more closely related).

- xen-api-backports
Similar to xen-api-libs-specs, but for Citrix's internal 'old
buildsystem' as opposed to Citrix's internal 'newer buildsystem'.

I don't think any of these is actually contentious - they probably
should never have been part of the Linux Foundation, and have been there
since we only had the one place on github to put things!



Third, we have some libraries that are actually mirage core libraries.
These should transfer over to the mirage organisation (remaining in LF,
as mirage is a Xen Project subproject like xapi):

- ocaml-gnt
OCaml grant table manipulation. This code originated in the mirage
project and was put here when it was split out of mirage-platform (see
here:
https://github.com/mirage/mirage-platform/commit/f532fc79af41e0e39b624a8e63dffc900bf1b7e4).

- ocaml-xenstore
This is the mirage implementation of a xenstore client library. Required
for running mirage kernels on xen. We use the unix-flavour of this
library. It also contains a WIP new version of the guts of a xenstore
daemon, which will be a mirage-style unix process _or_ unikernel
(xenstore stub-domain!) that should eventually be upstreamed into xen.

- ocaml-xenstore-clients
Slightly oddly named library that defines the unix transport mechanisms
(unix-domain sockets) for using the ocaml-xenstore library. This is the
unix counterpart to the internal shared-page mechanism used by mirage
unikernels.

- ocaml-evtchn
Similar to ocaml-gnt - split from the main mirage code at around the
same time as ocaml-gnt.

- ocaml-xenstore-xen
Unused by xapi-project. I believe in here lives the code that turns the
xenstore daemon library from ocaml-xenstore into the actual xenstored
stubdomain or process.



We have a few repositories that are forks of upstream repos with some of
our own changes in. We should get these changes upstreamed at some
point, but for now we should leave them there, but recognise that these
aren't necessarily part of the official Xapi Project (excepting where
they are, e.g. ocaml-xen-lowlevel-libs, which is a staging area for
upstreaming back into xen.git!)
- oclock
- ocamltest
- ocaml-xen-lowlevel-libs
- python-github2



Then there are generic ocaml libraries which could be used by other
ocaml programs. I think these can live on in the xapi project
organisation for now, but I wouldn't class them as 'core' xapi-project
repos.

- cdrom
- netdev
- ocamldoc-json
- ocaml-encodings
- ocaml-crc
- ocaml-fd-send-recv
- ocaml-netlink
- ocaml-opasswd
- ocaml-pci-db
- ocaml-qmp
- stdext
- stunnel
- nbd




Which leaves us with the 'core' xapi project repositories:

- blktap
- blktap-dkms
- example-ocaml-daemon
- ffs
- forkexecd
- libvhd
- message-switch
- ocaml-rrdd-plugins
- opam-repo-dev
- rrd-transport
- rrdd-plugin-legacy
- rrddump
- sm
- sm-cli
- squeezed
- tapctl
- vhd-tool
- vncproxy
- vncterm
- vxs
- wsproxy
- xapi-codegen
- xapi-libvirt-storage
- xapi-project
- xcp-eliloader
- xcp-guest-templates
- xcp-idl
- xcp-inventory
- xcp-networkd
- xcp-rrd
- xcp-rrdd
- xen-api
- xen-api-client
- xen-api-libs
- xen-api-libs-transitional
- xen-api-sdk
- xenops
- xenops-cli
- xenopsd

Of the above lists that will remain in the xapi project, these
repositories have incorrect forking status (they are marked as forks of
someone here at Citrix, but shouldn't be):

Forked from me (jonludlam on github):
xen-api-libs-transitional
xen-api-client
xcp-guest-templates
xcp-eliloader
wsproxy
tapctl
libvhd
blktap-dkms
netdev
nbd
cdrom

Forked from Dave Scott (djs55)
xcp-idl
vhd-tool
ffs
ocaml-vhd
ocaml-tar
ocaml-fd-send-recv

Forked from Simon Beaumont (simonjbeaumont):
ocaml-pci-db

Forked from Mike McClurg (mcclurmc):
ocaml-opasswd

These forking relationship problems need to be fixed by the people who
own the upstream repo. I don't think it's quite as simple as clicking
the 'transfer repository' button. If anyone knows the exact procedure
for doing this, could they please reply?


In summary, I believe we need to:
1) delete some repositories
2) move some repositories to xenserver
3) move some repositories to mirage-project
4) transfer ownership of some repositories (just flip around the
direction of the fork).
5) document all of this on the wiki!

Any comments?

Jon





_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api