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/
