couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [DISCUSS] Send Github new comment notifications to the dev list
Date Sat, 16 Mar 2013 17:00:08 GMT
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 <bchesneau@gmail.com> wrote:

> On Sat, Mar 16, 2013 at 8:44 AM, Noah Slater <nslater@apache.org> wrote:
> > Sigh.
> >
> >
> > On 16 March 2013 15:02, Benoit Chesneau <bchesneau@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message