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 Mon, 18 Mar 2013 14:26:23 GMT

On Mar 18, 2013, at 15:17 , Benoit Chesneau <> wrote:

> Jan, you can reject anything but that doesn't mean that my argument is
> invalid. And what this reject means by the way?

I meant to say “I don’t believe your argument is correct”.

> Also yes it will favor github, the latency introduced by manual
> updates will make the things impracticable unless you will be online
> 100% of the time. And i wouldn't want that you or anyone do that job.
> This is a painful job that is also imo doesn't adress the problem.

I will be online 150% the time if it is needed. Again, I expect the
need to do a manual copy to be *minimal*. Either way, the data will
be on dev@ first, favouring dev@ for most-real-time-info, and GitHub
second, that should align with your interests.

> Also people that are already sponsor the use of github will be
> encouraged to use it instead of using a system inside the apache
> system. Even some of the committers apparently.

And that is bad how?

> To answer to noah no I am not changing my position which was to be -0
> (and not +) . I will let a vote to decide. I am in disagreement with a
> solution that address only 20%
> of the problem. In my opinion we need a way that encourage people to
> use a neutral workflow from the beginning. And if we choose to use
> this 20% solution then we should also decide about a deadline to end
> it if it doesn't work and also a deadline to end it if we didn't
> figure to address the problem of having a 2 way channel.

Ok, let’s see how this goes and revisit in 12 months.


> - benoît
> On Sun, Mar 17, 2013 at 6:34 AM, Jan Lehnardt <> wrote:
>> 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.
>> Thanks
>> Jan
>> --

View raw message