[ocaml-infra] new Github projects under the "ocaml" organization

[Sylvain Le Gall]

+ infrastructure sorry

On Thu, Dec 8, 2016, 9:48 AM Sylvain Le Gall <sylvain at le-gall.net> wrote:

>
> Just to make it clear to everyone:
> The forge will be deprecated but I haven't made an official statement
> about it (pending). The official recommendation will be to migrate projects
> to Github, but I'll keep a STATIC website of the forge -- for the project
> that have no plan to migrate.
>
> Le mer. 7 déc. 2016 à 17:22, Amir Chaudhry <amc79 at cam.ac.uk> a écrit :
>
>
> > On 7 Dec 2016, at 15:28, Anil Madhavapeddy <anil at recoil.org> wrote:
> >
> > On 7 Dec 2016, at 15:14, Xavier Leroy <Xavier.Leroy at inria.fr> wrote:
> >> On 12/07/2016 03:43 PM, Anil Madhavapeddy wrote:
> >>> On 7 Dec 2016, at 14:15, Xavier Leroy <Xavier.Leroy at inria.fr> wrote:
> >>
> >>>> So, what is the policy?  how to request a new /ocaml/xxx project?
> >>>> who takes the decision?
> >>>
> >>> Technically speaking, you own the final say on the namespace,
> >>> so you make the decision in case of conflict :-)
> >>
> >> Not sure!  Before posting I re-read the governance document, in
> >> case my questions were already answered there.  According to this
> >> document, I do own the final say on hostnames in the ocaml.org domain.
> >> But the Github ocaml/ organization & namespace is something different,
> >> not covered (yet?) in the governance document.
> >>
> >> I suspect that, as one of the admins of this organization, I wield
> >> considerable technical power there as well.  But I definitely don't
> >> want to misuse or abuse it, hence my questions re: policy and
> >> procedure.
> >
> > Dear Xavier,
> >
> > Good point -- I will put GitHub on the list of things to add to the
> > governance doc. We also need somewhere to stash private keys
> > for infrastructure machines as well, so there are a few other items
> > of that nature that warrant a refresh.
>
> The governance doc was specifically written for the ocaml.org domain.
> Of course, it can be modified and extended to cover other things but the
> management and policy around code repos was not part of the original scope.
>
> I mention this in case anyone think it’ll be a trivial thing to add :)
>
> >>> So far, the policy has been any project that is reasonably needed
> >>> for the operation of the ocaml.org infrastructure. Some of them are
> >>> obvious: [...]
> >>> When we first created the GitHub org, it was also the home for
> >>> some popular community libraries: [...]
> >>> More recently of course, the OCaml compiler and its tools have
> >>> also started moving over: [...]
> >>>
> >>> So now that we have been using GitHub for a few years, there
> >>> is quite an array of libraries on the ocaml/ organisation, and
> >>> possibly time to do a garbage collection and disaggregate the
> >>> namespace if necessary.
> >>
> >> As far as the number of projects in ocaml/ remains tractable
> >> (e.g. tens, not hundreds), it's OK to host all of them and not
> >> worry too much about reorganization.  My (hypothetical) concern is:
> >> what happens do if, say, all projects from forge.ocamlcore.org ask to
> >> migrate to the /ocaml/ organization on Github?
> >
> > I have been wondering about this also.  Perhaps we should
> > take the initiative and create an ocaml-forge organisation that
> > mirrors the existing Forge Git repositories?
> > We cannot do much about issues, but it's fairly straightforward to
> > mirror the source code.  SVN will require an authoritative mirror
> > since the results of SVN2Git aren't always reproducible.
>
> IIRC Forge offers multiple features: Code, Mailing lists, and Issues.
>
> — Code —
> I would think that the correct analogy for this aspect of Forge would be
> GitHub itself. i.e. the maintainers move their repos/code to their own
> namespaces/orgs on GitHub.
>
> Some of those would make sense to move to /ocaml but that would involve a
> case-by-case discussion between the owners of /ocaml (i.e. you) and the
> maintainers of those codebases.
>
> Mirroring the existing Git repos into an ‘ocaml-forge’ organisation, as
> Anil suggests, might also be a good way to facilitate a mass migration.
>
> As a sidenote, there are benefits and trade-offs to moving projects into a
> GitHub organisation.  For example, the owners of a GitHub organisation have
> push access to all the repositories within their org, which is worth
> bearing in mind.  On the other hand, managing teams and collaborators is a
> little easier from within an organisation. Projects could make their own
> organisations if they wish — e.g. Merlin lives under an organisation rather
> than an individual’s account, https://github.com/the-lambda-church/merlin.
>
>
> Mass migration under an organisation is still an option for the Forge
> migration but:
> - it will generate quite a lot of work
> - lot of long discussions (some project may not want to be mass migrated
> to github, but would prefer GitLab or other)
> - probably only 20 migrated repositories will be active afterward
>
> There are probably 20-ish projects really active on the Forge, on top of
> 318 projects. I have 6 entries for people connecting to SSH to commit
> things in the last 6 months (3 of them are from me). So all in all, we are
> talking about 4 - 5 people using the VCS on the forge (like Xavier, me and
> another couple of people).
>
> Do we really want to migrate 318 projects for 20 active ones?
>
> My best guess would be to document how to migrate the VCS and let the few
> active people do it. I need to put in place a way to give the data back to
> people from the forge. The forge itself will be transformed into a static
> website at a certain point.
>
>
> — Mailing lists —
> It's possible to set up mailing lists on lists.ocaml.org and move
> archives over.  This has happened before so I don’t imagine any
> difficulties, other than logistics.
>
> — Issues —
> As Anil said, I’m not sure there’s much to be done about Issue Trackers
> and Task lists.
>
>
> Migrating issues will be a pain and was the thing that made me
> procrastinate over the last 6 months about the migration project. On the
> other hand, >45% of the opened issues are filed against OASIS project:
> OASIS: 45%
> Extunix: 8%
> OUnit: 8%
> Tuareg: 8%
> yypkg: 4%
> archimedes: 4%
> cryptokit: 3.5%
> ...
>
> You should not forget:
>
> -- Home pages --
>
> Some project actively use XXX.forge.ocamlcore.org as their homepages, we
> can suggest them to migrate to GH pages, but it will be pretty manual.
>
>
>
> > In Merlin's case, Fred also provided the mailing list archive,
> > so that has been migrated to lists.ocaml.org now:
> > https://github.com/ocaml/infrastructure/issues/5
> >
> >>> It would be great to keep the [libraries formerly in the compiler
> >>> distribution] underneath the ocaml/ organisation.  There is also
> >>> precedent for moving important core libraries such as Zarith into
> >>> ocaml/
> >>
> >> Duly noted.  But Nums and Zarith were two easy examples :-)
> >>
> >> Concretely: I'll try to work on the otherlibs/num -> ocaml/num[s]
> >> migration in the coming weeks, and will ask for help if I can't
> >> manage.  For other possible "immigrant" projects, let's give other
> >> people on this list time to think about it.
> >
> > Makes sense.  I am also CCing Sylvain onto this thread in case
> > he is not on the Infrastructure list.
>
> Since Sylvain is listed as Maintainer for a sub-domain he should already
> be on the infrastructure list :)
>
>
> I am ;-)
>
>
>
> Best wishes,
> Amir
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/infrastructure/attachments/20161208/cb5d670e/attachment.html>