Libguestfs - Jan 2012 - Development and hosting arrangements [new discussion thread]

[Let's start a new thread for this so all the mail archives will
appear in one place.  Please follow up on any of these items, and
hopefully we can formulate policy together.]

(1) Policy for commits.

[with thanks to Dan Berrange for helping to formulate this ...]

  "In order to become a committer, someone must demonstrate an ongoing
  skill posting patches of high quality and displaying a full
  understanding of the libguestfs code.

  "Once someone becomes a committer, they must post patches first to
  the mailing list.  Two ACKs from other committers are required for
  uncontroversial patches, and then the original committer is allowed
  to push the patch into the git development branch.  For patches
  which are posted by someone without commit rights, any committer may
  push the patch once the two ACKs are received.

  "Patches which are controversial cannot be committed until there is
  general agreement on the mailing list."

For commits to the stable branch:

  "Any committer who wants to make a new stable release may cherry
  pick patches from the development branch on to the stable branch, in
  accordance with the stable branch policy here:

  http://libguestfs.org/guestfs.3.html#libguestfs_version_numbers

  Posting the rebased patches on the mailing list and ACK-ing patches
  is NOT required."

(2) Hosting of the main website.

Current status: http://libguestfs.org is hosted on a semi-official Red
Hat-sponsored server.  We use ~ 1.4 GB of disk space on this server,
and some unknown but small amount of bandwidth.  We use a free Google
Analytics account for analytics.  The website is stored in a private
CVS repository.  In order to do a development release, you have to be
able to update the CVS repo and write to the front page.  For all
releases, you need to be able to drop the tarball into the download
directory.

Suggestions for hosting http://libguestfs.org ...?

(3) Hosting the git repository.

Current status: http://git.annexia.org/?p=libguestfs.git;a=summary is
hosted by RWMJ.  We use fedorahosted.org/git as a mirror / backup.  We
use 306 MB of disk space + a minor amount for hivex and febootstrap,
and an unknown but small amount of bandwidth.

It seems like the three candidates are going to be github, gitorious
and fedorahosted.org/git.  I have no particular preference, but for
github we need to think about who is going to pay for it.

(4) Hosting of official downloads.

Current status: http://libguestfs.org/download is hosted at the same
place as (1).  Because of the hosting arrangements, only Red Hat
associates are able to upload (enforced by policy and firewall rules).
In practice this means only RWMJ is able to make libguestfs releases.

I have no suggestions for this.  The archive is quite large, so it may
be hard to find free hosting arrangements.

(5) Hosting of other contributions.

Current status: We can't allow other contributions because of the
hosting arrangements.

(Same as (4)).

(6) Software for patch review.

I was quite impressed by gerrit (used by OpenStack amongst other
places).  At this time I don't think we need to worry about software
for patch review, and patch reviews should happen on the mailing list,
but we can discuss this.

(7) Mailing list, IRC.

Personally I'm happy with current mailing list and IRC arrangements.

(8) Changes to policy.

  "Changes to this policy can be made with the agreement of all
  committers."


Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

Richard W.M. Jones wrote:
> (3) Hosting the git repository.
>
> Current status: http://git.annexia.org/?p=libguestfs.git;a=summary is
> hosted by RWMJ.  We use fedorahosted.org/git as a mirror / backup.  We
> use 306 MB of disk space + a minor amount for hivex and febootstrap,
> and an unknown but small amount of bandwidth.
>
> It seems like the three candidates are going to be github, gitorious
> and fedorahosted.org/git.  I have no particular preference, but for
> github we need to think about who is going to pay for it.
You may want to consider http://repo.or.cz/