Le 27/04/15 15:10, Jochen Theodorou a écrit : > 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.
We never prentended that. But I'm quite sure the move to the ASF was not decided on the simple merit of which entity offer the best support for a DVCS... At least, I hope... > Costly here means loosing a part of the old community. The question would rather be : why have they decided to run away ? Were there active participant ? Have you made enough effort to keep them around ? I don't have any of those answers, all that I can say is that managing a large community is always a pain, you can't please every one, but at least, it *is* a community ! And when it comes to provide a decent degree of protection and tooling for such a community, Apahce is not the worst place to be ;-) > > [...] >>>>>> 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. Not sure if I get you point here. The ASF *protect* the committers against any legal action. It's not weak, it's really a complete umbrella. What kind of protection are you talking about ? > >> 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. I would rather argue teh exact opposite, and this is the reasons most of the Apache projects use CTR. Unless you meant RCT ? Yes, RCT is costly, and requires more workforce, and more delay. > Also can possibly work only for people that are already committer, Yes. > since otherwise you cannot do the first step in that. No, you can have someone who is not a committer, who send a pull request, which is reviewed by a committer. Actually, CTR works this way for external contributiions, and it's not really a huge pain. For RCT, that would again be more costly : not only you will need a committer to review the PR? but you would also need at least anouther committer to do the same. Btw, thsi is why we are quite liberal about adding new cmmitters : we don't have 36h per day to work on the project, so reviewing every contributiuon one can make is simply not scaling : better voting him after a few contribs have been validated... > 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. Yes. But again, are you taling about CTR or RCT ? > >> - 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. Indeed. And to save you time, better accept a contributor as a committer quickly than waiting for 100 PR from him ! In my experience, it's easier to mitigate a bad committer (someone who break the build with their commits) than to spend time reviewing every contribution for ever. At some point, you have to trust active contributors to be good committers ! > >> 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 Most certainly. There is no magic bullet, sadly :/ > > [...] >> 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. +1. The key here is to lower the barrier, which mean 1) use the right tool for the rigth task and 2) educating people. Not an easy and free atsk ;-)
