Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: [DISCUSS] Send Github new comment notifications to the dev list
From: Jan Lehnardt <jan@apache.org>
In-Reply-To: 
 <CAJNb-9pKhofrm7L7xPSRivTpvO=h2TABLsQBw1qKUU7n5=VvHg@mail.gmail.com>
Date: Mon, 18 Mar 2013 15:26:23 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7F173BC4-8A45-4064-85CE-15205E1E2391@apache.org>
References: 
 <CAPaJBx4iUwTOBUjpVyBs+q8TO=c+__D5ui3n1UZmC-G4Sga47A@mail.gmail.com>
 <731E2379-0031-4137-ABB4-78914713EF8C@apache.org>
 <CAJ_m3YDp36_058qcMQ42mf6VStS6v+1gSUDeB+jHGo4fB2Tv8A@mail.gmail.com>
 <65A80E2D-0742-4C12-9671-2BA4B8ED477E@apache.org>
 <CAJNb-9rW=e6M6C5rFwd5ESsWFEXDQVzoE_9OBpAXTkEQ+BPQKg@mail.gmail.com>
 <CAPaJBx7V6F2dg+Fc5xJfdEV0b1k=bRx3oAxkw8cZE=5imoFW_A@mail.gmail.com>
 <CAJNb-9ptArN77D9Aq70B-shh8upC+d3MmAKNn4x1oDO_tP4z=w@mail.gmail.com>
 <CAPaJBx547=-FTF1bzF_yoQDUbKtdhzVRbC3Z5+c1UVsgeyjPeQ@mail.gmail.com>
 <CAJNb-9qgiMdXeQ4EK07nDcz=5qTXEbLQSaRbWMjjv5x5fj8PjQ@mail.gmail.com>
 <04890552-61B6-468B-B5F4-73B024604DFB@apache.org>
 <CAGg-Cd6cKvcrad9sOrgpbL_x_O=Y3YkM2sqRzTgeVGX8gMKZGQ@mail.gmail.com>
 <CAAL6JQh9Ckv=TkJ4VuD4ZA8eB-8FRMidfVOb6_4PqxRSBv2piQ@mail.gmail.com>
 <763501E5-437F-4580-A6F7-31C07A33E529@apache.org>
 <CAJNb-9o1iF-EiEPxCSBEp2KaYy56fxuaoJKk6PXwEMPkn3AhZg@mail.gmail.com>
 <33F5D5E8-1913-495F-9442-AEF0BA2A6A84@apache.org>
 <CAJNb-9qPM+4W6vjs7Cwv0+jms=srk57psQ-_
 8DkdQ1U5x_sOjQ@mail.gmail.com>
 <7F425845-5281-4C69-8AE9-DA76014E618D@apache.org>
 <CAJNb-9pKhofrm7L7xPSRivTpvO=h2TABLsQBw1qKUU7n5=VvHg@mail.gmail.com>
To: dev@couchdb.apache.org


On Mar 18, 2013, at 15:17 , Benoit Chesneau <bchesneau@gmail.com> 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 =93I don=92t believe your argument is correct=94.


> 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=92s see how this goes and revisit in 12 months.

Cheers
Jan
--=20


>=20
> - beno=EEt
>=20
> On Sun, Mar 17, 2013 at 6:34 AM, Jan Lehnardt <jan@apache.org> wrote:
>>=20
>> On Mar 17, 2013, at 14:12 , Benoit Chesneau <bchesneau@gmail.com> =
wrote:
>>=20
>>> On Sun, Mar 17, 2013 at 5:50 AM, Jan Lehnardt <jan@apache.org> =
wrote:
>>>=20
>>>>=20
>>>> 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@.
>>>=20
>>> Is this thread read-only too ?
>>>=20
>>> 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:
>>>=20
>>> subscribed to apache
>>> 1. can read the comments
>>> 2. can't write to github
>>=20
>> - 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=92s the whole point.
>>=20
>>=20
>>> subscribed to github & apache
>>> 1. can read
>>> 2. can answer to github
>>=20
>> - all of this gets posted to dev@, making dev@ the *canonical*
>>   place to follow the development of CouchDB.
>>=20
>>=20
>>> And we all know (because of the "social" nature of github) that the
>>> moment we do that some will use more and more github
>>=20
>> That is exactly what we are trying to get after, make it easier to
>> contribute to Apache CouchDB.
>>=20
>>=20
>>> and at the end won't use anymore the means inside the apache =
foundation.
>>=20
>> I reject that this is going to happen necessarily. And I reject that
>> we set anything up that will paint us into that corner.
>>=20
>>=20
>>> and until
>>> wee find a solution for the other way some people won't be able to
>>> interact any more.
>>=20
>> 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).
>>=20
>>=20
>>> We aren't here to favourite one kind of users.
>>=20
>> We aren=92t doing that.
>>=20
>>=20
>>> What do we do for others, do we also add their systems?
>>=20
>> 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=92d be all up for making that happen as well, but it is =
completely
>> unrelated to whether we do the GitHub thing now.
>>=20
>>=20
>>> What do we do for companies that can't for any reasons use github?
>>=20
>> dev@ is canonical, they can email.
>>=20
>>=20
>>> 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.
>>=20
>> 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.
>>=20
>>=20
>> * * *
>>=20
>>=20
>> I want to reiterate what Noah brought up earlier:
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> There is a distinct line between moving something towards a place =
where
>> we are happy shipping it and shipping half assed solutions or ideas.
>>=20
>> 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.
>>=20
>> We have done this for long enough and I won=92t allow this project to
>> stall any longer because of some half-baked criticism that kills the
>> early stage of an idea or patch.
>>=20
>>  I know Noah has a list of these anti-patterns of feedback and I
>>  hope he can post them here.
>>=20
>>=20
>> * * *
>>=20
>>=20
>> 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.
>>=20
>> Now that we have addressed that particular concern, let=92s move on.
>>=20
>> Thanks
>> Jan
>> --
>>=20
>>=20