Mailing List Archive

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@lists.xen.org; mirageos-devel@lists.xenproject.org
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@lists.xen.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api

On 10/06/2014 10:49 AM, Jon Ludlam wrote:
> 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?

What I've done in the past is clicked 'transfer repository' to xapi-project or xenserver, then forked back to my own account.

This seemed to work fine. I might only have done this with repos that had only a master branch, so we should make sure it works with repos with multiple branches (but I can't see why it wouldn't).

John

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

On 10 June 2014 at 10:49 AM Jon Ludlam wrote:
> 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.

[snip]

> 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?

I'm not confident that it is possible to just designate a different
fork as the "upstream" one.

A while back I'm fairly sure it wasn't, though perhaps github has
made changes since then.

It looks as if it would be possible to transfer the repository, but this
Isn't really want as we'd need to get the "upstream" one into the right
state, and would have to jump through some hoops with memberships
and renaming:
https://help.github.com/articles/how-to-transfer-a-repository

If the "upstream" owner were to delete his fork then a new fork will be chosen
as the new "parent" repository, though the github documentation doesn't
make it clear whether this is chosen by a github algorithm or by the user
doing the deletion:
https://help.github.com/articles/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility


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

>> 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?
>
> What I've done in the past is clicked 'transfer repository' to xapi-project or xenserver, then forked back to my own account.
>
> This seemed to work fine. I might only have done this with repos that had only a master branch, so we should make sure it works with repos with multiple branches (but I can't see why it wouldn't).

Indeed, this should work fine, we did it plenty of time with mirage repos. Github also automatically sets up redirect, so everything is transparent for users.

Thomas


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

Thomas Gazagnaire wrote:
> >> 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?
> >
> > What I've done in the past is clicked 'transfer repository' to xapi-project or
> xenserver, then forked back to my own account.
> >
> > This seemed to work fine. I might only have done this with repos that had
> only a master branch, so we should make sure it works with repos with
> multiple branches (but I can't see why it wouldn't).
>
> Indeed, this should work fine, we did it plenty of time with mirage repos.
> Github also automatically sets up redirect, so everything is transparent for
> users.

Good to know, though there would still be a certain amount of hassle
involved in getting the initial parent repository into the right state, moving
the xapi-project fork aside and so on.

I asked Github Support for advice, and received this:

> We can make a repository the root in the fork network if we receive
> confirmation from the owner of the repository which is the current
> root in the fork network.

> If you get the owner(s) of the current fork network root repositories
> to email us directly, we can make the adjustment to the fork network
> as requested.

This looks like the easiest approach.

Thomas Sanders


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

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@citrix.com> 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@lists.xen.org; mirageos-devel@lists.xenproject.org
> 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@lists.xen.org
> http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api


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

Hi,

> 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):

There are also a couple of libraries that I've developed while I was in Citrix (and still continue to maintain since then) which are used by xapi and which I could move to the mirage organisation as well:

- https://github.com/samoht/ocaml-rpc
- https://github.com/samoht/ocaml-tar (which has been forked by djs55)

What do you think ?

Thomas


>
> - 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@lists.xen.org
> http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api


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

On 18 Jun 2014, at 12:24, Thomas Gazagnaire <thomas@gazagnaire.org> wrote:

> Hi,
>
>> 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):
>
> There are also a couple of libraries that I've developed while I was in Citrix (and still continue to maintain since then) which are used by xapi and which I could move to the mirage organisation as well:
>
> - https://github.com/samoht/ocaml-rpc
> - https://github.com/samoht/ocaml-tar (which has been forked by djs55)

Moving both of those to Mirage makes sense to me, as they're policy-free and fairly easy to plugin. Ocaml-tar in particular seems to have done the rounds among all the organizations :-)

-anil



> What do you think ?
>
> Thomas
>
>
>>
>> - 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@lists.xen.org
>> http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
>
>
> _______________________________________________
> Xen-api mailing list
> Xen-api@lists.xen.org
> http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
>


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

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@eu.citrix.com> 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@lists.xenproject.org
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel


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