groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maarten Boekhold <>
Subject Re: PR and workflow [was [ANN] New committer: Shil Sinha]
Date Sat, 24 Oct 2015 14:12:20 GMT
Maybe apache can ask atlassian if they can get an installation of bit 
bucket for free?


On 24 October 2015 13:56:20 Thibault Kruse <> wrote:

> On Sat, Oct 24, 2015 at 11:28 AM, Jochen Theodorou <> wrote:
>> On 23.10.2015 13:47, Jim Jagielski wrote:
>>> You do know, of course, that this workflow that has been used for
>>> decades at the ASF was started by and built-around and designed-for
>>> unpaid volunteers to do just that, right?
>> Oh,I would be careful with "used for decades". Just because people don't
>> know it better and got used it, doesn't mean it is good. I would for example
>> not want to change from Git (or Subversion) to CVS, just because CVS is in
>> use for decades. Back then, there was no real alternative. Today times are
>> different and there are different established workflows. And you know that
>> most people don't go to the extra effort of changing their established
>> workflow, just for a small commit. That means less contributions, which
>> means in the end less committers.
>> Times change and so do the methods.
>> The only reason I see to keep the centralized singled repo way is for legal
>> reasons. And since that is a very strong reason there is nothing really to
>> discuss with github for the moment. Unless there is some kind of cooperation
>> between apache and github, or apache offers something like github (I doubt
>> there is enough manpower for that).
> 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".
> Apache could set up something like gitlab for their repos,
> (,
> without too much manpower involved.
> 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.
> 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.

View raw message