couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: [DISCUSS] Send Github new comment notifications to the dev list
Date Sun, 17 Mar 2013 13:34:18 GMT

On Mar 17, 2013, at 14:12 , Benoit Chesneau <> wrote:

> On Sun, Mar 17, 2013 at 5:50 AM, Jan Lehnardt <> wrote:
>> My proposal includes that nobody is forced to use GitHub. All discussions
>> can happen without ever touching GitHub now and in the future. My proposal
>> was designed to take this into account. Please stop bringing this up as
>> an argument against the proposal to send GitHub comments to dev@.
> Is this thread read-only too ?
> This is were is the issue in the proposition, it doesn't solve the
> problem of the pr. We need to make sure that the ml is the main hub.
> We can't just put out a partial solution because the balance will be
> in disfavour of the apache ml:
> subscribed to apache
> 1. can read the comments
> 2. can't write to github

 - fixed by my manual copying to GitHub. It will my *my personal
   responsibility* to make sure the GitHub side stays useful.
   dev@ *remains* the canonical place for information.
   That’s the whole point.

> subscribed to github & apache
> 1. can read
> 2. can answer to github

 - all of this gets posted to dev@, making dev@ the *canonical*
   place to follow the development of CouchDB.

> And we all know (because of the "social" nature of github) that the
> moment we do that some will use more and more github

That is exactly what we are trying to get after, make it easier to
contribute to Apache CouchDB.

> and at the end won't use anymore the means inside the apache foundation.

I reject that this is going to happen necessarily. And I reject that
we set anything up that will paint us into that corner.

> and until
> wee find a solution for the other way some people won't be able to
> interact any more.

I consider this an edge case that I, again, am happy to find a technical
solution for. Until then, I do it by hand. Making automatic two-way-sync
a blocker seems overly zealous to me, when the whole idea is to get info
to dev@ that is currently not on dev@ and clearly harms the visibility
of the dev efforts of the project today (and as Noah points out for the
past 24 or so months).

> We aren't here to favourite one kind of users.

We aren’t doing that.

> What do we do for others, do we also add their systems?

We can integrate them the same way the second they come up. I answered
that question before. Also, this is another attempt at derailing this
conversation and I wont stand for it. Whether we make GitHub integration
better has nothing to with whether we *also* make Google Code integration
better. I’d be all up for making that happen as well, but it is completely
unrelated to whether we do the GitHub thing now.

> What do we do for companies that can't for any reasons use github?

dev@ is canonical, they can email.

> So my point is that if we go for this solution (and if it's legally
> acceptable) we must go with the complete solution, not a partial. Ie
> we should have r/w the moment we start it. Not *eventually* later.

Having someone copy mails to GitHub manually is a complete solution.
It is just not an automated solution, but since I will be the someone
I accept that reality. And this is one of the cases where I will be
more than happy to be replaced by a shell script.

* * *

I want to reiterate what Noah brought up earlier:

We are trying to fix a situation that has been bad for the visibility
of the development of the project for a long time. Currently there is
data relevant to the development of Apache CouchDB locked into GitHub
and that is a very bad idea as it stands and going forward. We are trying
to address this by automating a way to get that data to dev@ in a more
automated fashion. We also establish a policy (that can be replaced by
code in the future) that enables data flow back to GitHub.

And now that we are bringing this up we get all sorts of FUD how this
is bad and I fail to understand why getting relevant data to dev@ is
in anyway bad and should not be implemented because there is some more
automation to be done.

Historically, we have seen a lot of stalling of progress in this project
because a proposal only went 80%. There are a number of typical
responses that kill the effort because somehow we need a 100% solution
before we move on.

There is a distinct line between moving something towards a place where
we are happy shipping it and shipping half assed solutions or ideas.

In early stages all solutions and ideas are half-assed, but they are
the most precious thing that we have that brings the project forward.

We have done this for long enough and I won’t allow this project to
stall any longer because of some half-baked criticism that kills the
early stage of an idea or patch.

  I know Noah has a list of these anti-patterns of feedback and I
  hope he can post them here.

* * *

Finally, I want to make sure that I state this again: I am 100% 
behind the notion that an Apache Project needs to ensure vendor
neutral communication channels. I am glad we went through the
exercise of making sure that the proposed solutions does not
paint us into a corner.

Now that we have addressed that particular concern, let’s move on.


View raw message