Re: [Xen-API] [MirageOS-devel] Xapi project repositories

[Amir Chaudhry <amc79@xxxxxxxxx>]

Hi folks,

Since the Mirage release is fast approaching, I'd like to get the repo 
transfers in order.
Extracting from Jon's email below, here is where things stand with respect to 
the Mirage libs.

    *ocaml-xenstore*
    xapi-project is the current root
    An admin must initiate transfer to the Mirage org
    https://github.com/xapi-project/ocaml-xenstore/settings

    *ocaml-xenstore-xen*
    xapi-project is the current root
    An admin must initiate transfer to the Mirage org
    https://github.com/xapi-project/ocaml-xenstore-xen/settings

    *ocaml-xenstore-clients*
    djs55 is the current root
    Dave to transfer his personal repo to the Mirage org
    https://github.com/djs55/ocaml-xenstore-clients/settings

    *ocaml-gnt*
    Already transferred

    *ocaml-evtchn*
    Already transferred

Dave, could we please move the three remaining libraries to the Mirage org as 
soon as possible please?
It's a fairly trivial process and is transparent to end users.  I've even 
included links that should take you to the exact page where you can click the 
transfer button. :)
If there's some blocker to this, please let me know.

Best wishes,
Amir


On 10 Jun 2014, at 10:48, Jon Ludlam <jonathan.ludlam@xxxxxxxxxxxxx> wrote:

> 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
> 
> 
> 
> 
> 
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel


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