groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russel Winder <>
Subject Re: PR and workflow [was [ANN] New committer: Shil Sinha]
Date Sun, 25 Oct 2015 09:29:57 GMT
On Sat, 2015-10-24 at 11:56 +0200, Thibault Kruse wrote:
> I believe the alternatives right now are between a single centralized
> repo at
> apache vs. a single centralized repo at github, so I see no need to
> always mention
> "centralized single".

The big point is that Apache has a bare repository whilst GitHub (and
BitBucket) surround this with extra technology for handling changesets
that is now seen as integral to good community. One of the reasons
behind the decline of Codehaus was exactly that in shifting from
Subversion to Git it assumed it need only support the repository and
failed to realize that in the shift from CVCS to DVCS you have to
change your view on supporting the community. With CVCS the repository
is all there is. With DVCS the repository is just a fraction of the
technological support the community associated with that project needs.
GitHub provides a lot of that support and it revolves around public
pull request management and review.  

> Apache could set up something like gitlab for their repos,
> (,
> without too much manpower involved.

I have no experience of GitLab, but in other places people have said
they are using it in preference to a private GitHub instance, because
it is free to use. They report that it isn't quite as nice as a private
GitHub instance, but it is nonetheless very usable.

As I mentioned in my reply to Jim, an alternative is to set up Gerrit
around the Apache repositories and to not use GitHub for pull requests,
just for repository distribution.
> Or Apache could decree that it is acceptable for projects to use
> github to merge PRs
> before syncing them to the "primary" repository at apache, and set up
> syncing support
> with commit hooks.

As an interim measure, till Apache puts some more DVCS support
technology in place, I think this would be a good thing, as I already
said in my reponse to Jim.

> Since the word "primary" is open for interpretation, it might be
> possible to convince
> Apache that what makes a repo primary for a project is that releases
> are made from
> that repo, not that all merges are done there first.

No need for this worry about primary: the Apache repository is the
primary mainline because it defines the state of the project. GitHub is
a secondary mainline since it is where the work happens, but it is not
part of the definition of the state until it is reflected in the Apache
repository. There is no doubt here, just a change in workflow that
allows GitHub pull request management to be used to its full.

Dr Russel Winder      t: +44 20 7585 2200   voip:
41 Buckmaster Road    m: +44 7770 465 077   xmpp:
London SW11 1EN, UK   w:  skype: russel_winder

View raw message