Re: [Xen-API] Xapi project repositories

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

Thanks Jon -- I agree with all these changes.  In addition, I'm going
to move the OCaml-GitHub bindings to the Mirage org as well.  This way,
any future 'summary-of-the-week' binaries can also benefit both Mirage
and the Xapi project, and not be sitting in a personal repository.

Lars: I will get you the final repo list for Bitergia just as soon as 
all this shuffling is done.  We'll have a canonical list for the Mirage 2.0
release.

best,
Anil

On 10 Jun 2014, at 11:05, Lars Kurth <lars.kurth@xxxxxxxxxx> wrote:

> Hi all,
> 
> when you have the final list of repos for xapi and mirage. Please send it to 
> me such that I can update the bitergia dashboard
> 
> Still need to get the Mirage list, which I have been waiting for for several 
> months.
> 
> @Jon. Do you want press coverage for XAPI 2?
> Can talk to you on Thursdays
> 
> Lars 
> ________________________________________
> From: Jonathan Ludlam
> Sent: 10 June 2014 10:48
> To: xen-api@xxxxxxxxxxxxx; mirageos-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Lars Kurth
> Subject: Xapi project repositories
> 
> 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


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