Mailing-List: contact dev-help@groovy.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@groovy.incubator.apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 elecharny@gmail.com does not designate 54.191.145.13 as permitted sender)
Message-ID: <553E2312.5030001@gmail.com>
Date: Mon, 27 Apr 2015 13:52:50 +0200
From: =?UTF-8?B?RW1tYW51ZWwgTMOpY2hhcm55?= <elecharny@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: dev@groovy.incubator.apache.org
Subject: Re: New =?UTF-8?B?V29ya2Zsb3figKY=?=
References: <1429345996.2703.19.camel@winder.org.uk>
	 <CAJ2HCd-Ka0+mUf=b27s+bnkNAWL=QgVaDtznkEqvaE_NDBB62Q@mail.gmail.com>
	 <1429373705.31282.12.camel@winder.org.uk>
 <5532922C.4000800@gmx.net>	 <55329371.60408@gmx.net>
 <1429448854.3327.4.camel@winder.org.uk>	 <5533FEC1.5070502@gmx.org>
	 <CAJ2HCd8M3fnFD8akWM4wXR9myT7DGoKkQvqsFgXOz+nuD3HoGA@mail.gmail.com>
	 <CAPbPdOYqiYgvMR_8Ty93vps2VP0WaFsVHeVy-eUmvtUFdnEUCQ@mail.gmail.com>
 <1430064098.8938.6.camel@winder.org.uk> <553D1621.5080608@gmail.com>
 <553DF0BB.6080305@gmx.org> <553DFD81.6040302@gmail.com>
 <553E070D.9090908@gmx.org>
In-Reply-To: <553E070D.9090908@gmx.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Le 27/04/15 11:53, Jochen Theodorou a =C3=A9crit :
> Am 27.04.2015 11:12, schrieb Emmanuel L=C3=A9charny:
> [...]
>> And it took weeks of work to find a new home and to migrate everything=
=2E
>> Something you want to do again ?
>
> If it had been only the git repo it would not have taken weeks. It
> took weeks because there is a community, there are mailing lists and
> bug tracker with extensive history. Both things git does not really
> provide (I don't consider the github bug tracker a suitable tool for
> bigger projects).

My point was not that migrating the repo was costly. My point is that
depending on some private company infra, whatever it is, and here, it's
github, makes it costly and difficult to migrate. Most certainly when it
also involves a huge community.
>
>>> In git everyone has the full repo locally as well, as long as it is
>>> updated. You can do shallow copies in git, but they are not standard.=

>>
>> Standard for The ASF means something that we can bring to a juge, if
>> needed. This is quite complicated to guarantee if we don't have the ma=
in
>> repo in our walls.
>
> which is difficult to understand, since there is no reason given for a
> why and what exactly is missing. in other words: details.

Details is what matters when in front of a court...

>
> [...]
>>>> Last, not least, we protect *committers* against any legal action,
>>>> committers being voted people. Being able to give access to a select=
ed
>>>> number of person who have signed a CCLA/ICLA is a key for The ASF,
>>>> something you are not likely to be able to enforce in github (and
>>>> if you
>>>> can, again, we have no guarantee we can control such protecion for
>>>> ever)
>>>
>>> Well, following this strictly we should never ever merge pull request=
s
>>> from github
>>
>> Why ? The committer who push such pull request does it under his own
>> responsability...
>
> which means, that in such a project there is no protection for the
> committer in the end

Of course there is, and this is why committers have to sign a CLA ! It's
clearly stated in The ASF web site :

http://www.apache.org/licenses/#clas
"The purpose of this agreement is to clearly define the terms under
which intellectual property has been contributed to the ASF and thereby
allow us to defend the project should there be a legal dispute regarding
the software at some future time."

and regarding responsability of a committer who push some code into the
repo :

https://www.apache.org/dev/new-committers-guide.html#responsibilities
"Each committer has a responsibility to monitor the changes made for
potential issues, both coding and legal."

Bottom line, *review the code you receive* !!!

>
>>>> Hope it clarifies why we push commits to the ASF Git repository.
>>>
>>> You mean clarifies why we have to push commits to the ASF Git
>>> repository as primary repository.... and not really to be frank.
>>
>> Sorry, but I don't see what is your problem them, beside some
>> philosophical aspects...
>
> As long as there is no comparable tool for pre-commit reviews and easy
> usage on ASF,=20

But there are many tools available, considering you can use github. Also
what is important is what is in the release, which means that if you
push somthing that need to be reviewed in a safe zone - say, a branch- I
don'tsee what's the problem.

In fact, you have two ways to get things done :
- most of the time, c-t-r is the way to go (Commit Then Review). It's
fast, easy, and convenient.
- for some critical projects, it's r-t-c (Review Then Commit). I think
this is what httpd is doing. If you think that the groovy project is at
risk then switch to r-t-c.

FTR, I deal with pull-requests for the MINA project, and it works simply
fine. I can review the code, and I can decide to apply it - or not.

At this point, The ASF does not limit you to use tools that help to do
code review. The only constraints is that the code *must* be pushed into
the ASF repo by a committer, period.

> there is a practical acceptance problem. That's all.

I can understand. I think there are many ways to workaround this
'acceptance problem', and explaining how it all works is one of them ...