Benoit, I said I thought we have three options: 1) Ignore them 2) Discourage them 3) Embrace them
At the moment, we are doing 1. I have made a proposal that would have comments on PRs being sent to the list. And I am hoping this helps to convince individuals to start doing 3. But I my proposal makes no explicit changes to policy, or whatever. When you say rejecting them, I presume you mean posting a comment on the PR saying "we don't accept contributions via Github. Please follow [URL] which explains how to submit a patch." I believe this is option 2, or a variant. I think this would be bad for the project. And if we were going to do this, I would actually suggest we just get rid of the Github mirror. It seems damaging to have a mirror there if all we're gonna do is reject PRs sent to it. What I would like to suggest, however, is that if you feel strongly about this, you start a separate DISCUSS thread, and you set out your proposal in some amount of detail, and try to get consensus around it. Please note, my tone might be a bit bullish at time, but I don't get to tell anyone what to do. If this is something you feel strongly about, then you should go ahead and try to build up consensus around it. I would note, however, that it does not conflict with my proposal. (The one we're discussing in this thread.) So, I think the two things are separate. And you have voted +0 on my proposal. So unless someone votes -1 in the next few days, I am hoping that we can get comments sent to the mailing list. I guess if you manage to get consensus around your idea, then those comment notifications go away anyway. But I would like to keep the two topics separate. Without wanting to shut down your idea or whatever. On 16 March 2013 16:51, Benoit Chesneau <bchesn...@gmail.com> wrote: > 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. > -- NS
