groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: New Workflow…
Date Mon, 27 Apr 2015 13:10:34 GMT
Am 27.04.2015 13:52, schrieb Emmanuel Lécharny:
> Le 27/04/15 11:53, Jochen Theodorou a écrit :
>> Am 27.04.2015 11:12, schrieb Emmanuel Lécharny:
>> [...]
>>> And it took weeks of work to find a new home and to migrate everything.
>>> 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.

well, if you say there is a community which is only on github, then it 
stays costly to move that to the ASF, since the ASF does not give the 
same ease of use and comfort level that github does. Costly here means 
loosing a part of the old community.

[...]
>>>>> Last, not least, we protect *committers* against any legal action,
>>>>> committers being voted people. Being able to give access to a selected
>>>>> 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 requests
>>>> 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 !

just saying that the protection argument is weak, since it is too easy 
to not be protected anymore.

[...]
>>>>> 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,
>
> 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't see what's the problem.

more work is one

> 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.

ctr in terms of commit, check, approve is too time consuming. Also can 
possibly work only for people that are already committer, since 
otherwise you cannot do the first step in that. With that, this process 
is useless for the group of people where it is most needed: newcomers 
and striving to be committers. Which means you need a review before 
commit in any case.

> - 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.

In general it has the same time problem, only that you have to deal less 
with broken builds, but the review time will be  there as well of 
course, and if you have to do this for every commit, you better have an 
not too active project or you are going to be crazy or spend a lot of 
time. But for new contributors, this is the better way in my experience.

> 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.

sure, I was just pointing out, that Gerrit is for me most likely no 
replacement for github

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

just explaining won't do if the entrance barrier is too high.

bye blackdrag

-- 
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/


Mime
View raw message