On Sat, Mar 16, 2013 at 8:44 AM, Noah Slater <nsla...@apache.org> wrote: > Sigh. > > > On 16 March 2013 15:02, Benoit Chesneau <bchesn...@gmail.com> wrote: >> >> >> Well, I don't see the need "to play around with". > > > Because nobody else is doing anything. I am trying to do something. And I > feel like I am being shut down by nay sayers who have nothing better to > contribute than stop-energy. > > >> The fact is that PR are introducing a one way to discuss about pull >> request except if you >> also forward the mails from dev@ to github. (which can be quite >> complicated). So people will have to connect on github to answer to a >> PR or get the patch. This isn't a progress at all imo. More likely a >> regression in our social contract with the community. >> > > How can this be a regression? You've just described the status quo. We've > been getting pull requests on Github since *two years ago*. We've literally > had this problem for 24 months or more. And you know what happens to these > pull requests? They are ignored? And do yo know why? Because nobody is > looking at them. And this is supposed to be a net positive for our > community? > > >> Having the PR on github is removing some part of our neutrality >> against vendors since you have to sign in a third-party website to >> participate. > > > Do you really think I am proposing to use Github as the official CouchDB > patch submission process? > > I am pointing out that people are using Github to submit PRs. This is a > thing. This is a fact about the world. I neither caused it, or am able to > stop it. It's just a thing that is happening. > > We have three options: ignore it, attempt to shut it down, or embrace it. > > >> Which is in some cases not possible for some companies or >> individuals due to their location or company policy. While having to >> sign to an independent foundation ml is most of the time possible. >> > > This is irrelevant. Because I am not suggesting that we move our code to > Github, or that we start to solicit patches through Github, or that we make > PRs the official way to do things with CouchDB. > > If you want to work with Paul, and Matt, and Wendall, and whoever else to > come up with a contributor workflow that describes our preferred method of > patch submission, then fantastic. Absolutely fantastic. > > What I am suggesting is that we also mention that if you *are* going to > send a Github PR, then this is how you do it. And also suggesting that we > sit it up so the dev list gets notifications about what is going on over > there. > > Again. Please note: I am not suggesting we change our workflow. This is > what is so maddening about this entire discussion. I am suggesting that we > get email notifications about comments on Github. That's it. No other > changes. But people are arguing with me about the *philosophy* of Github, > and contribution workflows, and all kinds of completely incidental stuff. > > Listen, if you wanna sort that shit out. By all means. Someone should! It's > clear people are confused about how to contribute to CouchDB. But I would > also maybe point out that it's been like this for 24 months and nobody > seemed to give a shit. > > But I suggest we get comment notifications to increase visibility and > suddenly everyone cares about the subject. And suddenly Github itself is > the problem and we should just stop everything we're doing to work on that. > > >> PR aren't connected to jira tickets. Is the next step to jump on github >> tickets? >> > > Seriously? > > Again: I am just going to keep repeating this until it becomes > repetitive and obvious to everyone involved. I am not proposing to change > anything about how we are working. I am not proposing any changes in > policy, or workflow, or anything. Nada. Nothing. Zip. Zero. No changes. > > We have been accepting PRs for *two years* now. And if you're not happy > with them, why have you done nothing about the situation until now? Why is > it suddenly relevant when propose that the dev list gets to see comment > notifications? > > >> PR is one more code code canal to follow. also when someone open a PR >> where to answer? Jira, github, ml, ? >> > > Why do you keep phrasing it as if I am only now proposing we start > accepting pull requests on Github? We've been accepting PRs for *two years* > and so far our average response has been to ignore them. So I guess you are > free to carry on like normal and keep ignoring them. Nobody is requiring > anything from the committers, or anyone else for that matter. > > Again: I am not proposing we change anything about our contribution > workflow. (Though, give the recent feedback from contributors to this > project, perhaps we ought to have a serious think about how we could be > doing this better...) > > All I am proposing is that we get new comment notifications from a service > that people think we're using, but we seem to be mostly ignoring. > > >> In short I would really prefer we kill the PR support asap > > > There is no way to do this without deleting our Github mirror. I have > explained this a number of times now. There is literally no way to turn of > pull requests. If you are on Github, then you can get pull requests. That's > how it works. > > >> and propose a clear way to submit patches via the ml and jira > > > False dichotomy. This is not a "one or the other" situation.
Why it couldn't be that. People aren't blind, they can read a contributing documentation and know where and how to propose patches that can be accepted by the project. > > If you want to propose a clear contribution guide, then please do so. > Please mention what our preferred patch submission methods are. This should > include JIRA, email, Github, and anything else you can think of. > > >> It doesn't mean like you say, that we have to close the mirror > > > Yes it does. That's how Github works. I'm not sure what you mean here. Not accepting doesn't require anything technical if it's what you mean. It is a project decision. > > >> No. Having a mirror is still useful for those who are using github, to >> fork the code and >> having a... mirror. > > > Why do people fork on Github? To send back pull requests. Some do it for that. Others do for to keep track on the project activity. Otheres for their own reason. Some of us were also using github before it had PR looking like it is today. > > >> So it's not about killing the mirror, but not accepting PRs. >> > > By "not accepting" do you propose that we ignore them? no. we don't accept them. and make it clear. We don't have to ignore when we don't accept. > > do you really think it's better >> to put all the metadata of our code in the hand of a private company >> rather than having in an independent system (backed by the foundation) >> and your hands? > > > So ironic, given my proposal. > > I am suggesting that we get a copy of all of the comments on a PR sent to > our mailing list. I am literally suggesting that we export the information > on Github into our mailing list. You missed the part where I was saying it was a one way communication channel. Except if you also put the response from the @dev ml to github. Othere than that it's pretty useless as a communication channel. Only useful for archives. > > >> We aren't speaking about the code only here, but about >> all the things that come with: discussions, comments etc. >> > > Yep. That is *literally* the *exact* problem I am trying to solve here. > > I am just taken aback by all of this. What on earth do you think I am > proposing that you would bring up points like this? Or that you would > suddenly start to question something you see as a "regression" which has in > fact been going on for *two years*. > > To be frank, the way that we deal with contributions to this project, I > think we're lucky to be receiving pull request in the first place. I think > it is the hight of arrogance to start talking about how we should ignore > them, or somehow discourage it. Especially when we have such an obvious > work-around for making sure that all the important activity gets sent to > the list. How do you think code contributions go in project like linux, or others project like? They have only one canal for that. > > I actually think there's a little bit of ideological "us and them" going on > here, and I have no patience for it whatsoever. I could say the same. Anyway on the contrary I want to make sure to keep the contribution process completely neutral. What about launchpad, bitbbucket, google code, gitorious, .... . I want to make sure that people don't have to take an account on github to answer or participate to a patch. It's isn't about me, I have a github account, neither us. It's about others. > > I proposed that we set up Review Board. Review Board *could* have been the > place that we pointed new contributors to. We could have said "hey, Github > is cool and whatever, but can you submit your patch to this ASF run Review > Board? That's how we prefer contributions to come in, and we can comment on > it there, and thank you very much, etc!" > > You know how many times I proposed Review Board to this list? Twice. Once > on 2012-09-08 and a second time on 2013-04-10. Literally, only six days > ago. And do you know what sort of response I got? Apathy. Jan made an > interesting comment that many people asked for Github PRs before we had > them, but nobody has asked us about Review Board. So it seems that review board didn't have so much success that all. Which doesn't mean we don't (at least I) want to improve the current situation. The proposed solutions can differ. That all. And I think that proposing to not accept PRs for the reasons I give is a possible solution. At least the one I support. > > So if this is something y'all cared so much about all along, why did I get > no responses when I was proposing a patch submission tool that we might've > been able to steer people to instead of Github? And why the > disproportionate reaction when I suggest something as simple as sending > through comments to the mailing list? Is it because Review Board is a big > change, and comment notifications are a small change? Is this a bike shed? > What other possible reason could there be? > > If you're so against things happening away from the foundation, Benoit, why > did you take the initiative to start a Google+ community? I mean, that is > explicitly a silo of activity that you can only participate in if you have > a Google+ account. (And I know a few people who refuse to sign up for > Google accounts on ethical/privacy grounds. I do not know of anybody who > refuses to sign up for a Github account.) And why did it take me to bring > up the idea of curating Google+ content back to the lists? > > Let's get this straight: I think it was a good idea to start the Google+ > community, and I thank you for it. But I think it's a remarkable piece > of hypocrisy for you to hit out against a minor proposal I make about > Github, on some pseudo-moralistic grounds about it being an external > service that people shouldn't have to feel obligated to use. And nobody is > using it anyway, and I am not proposing that you have to use it, or even > that we move any activity over there. I am simply proposing that we get > visibility into anything happening on Github. Which as it stands, would be > more than we currently have in place for Google+. > how is it related? You're comparing informal discussion channel around the project (which can happen afk) vs core code contributions. I make a clear distinction between them. Marketing (aka project "visibility") and code contribution workflow are different from me. And I don' think we should mix them.
