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 18:06:17 GMT

On Mar 18, 2013, at 18:57 , Eli Stevens (Gmail) <> wrote:

> Every single email I get from a github pull request contains a header like:
> Reply-To: mobius-medical/dev <
> And sending email to that email address causes the content of that email to
> show up in the pull request.
> Unless public repos behave differently in this regard from private ones
> (which is what I'm using when I see these), it seems like we can solve the
> content mirroring issue *trivially*.  Nobody needs to volunteer to be
> online 150% of the time for anything.  If someone on the ML wants to have a
> reply appear in the PR, then you make sure the address is
> CCd.  If you don't, then just send to the ML.
> Is all of the discussion about github PRs unaware of this current
> email-to-PR-comment bridge, or is there some non-obvious inadequacy (in
> which case it should be spelled out)?

Thanks for pointing this out, I looked at this as well, but then had to write
lengthy emails instead.

My 150% number is only to illustrate the futility of this argument.


> Eli
> On Mon, Mar 18, 2013 at 7:51 AM, Jan Lehnardt <> wrote:
>> On Mar 18, 2013, at 15:46 , Benoit Chesneau <> wrote:
>>> On Mon, Mar 18, 2013 at 7:26 AM, Jan Lehnardt <> wrote:
>>>> 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”.
>>> Yes so what does it means?
>>>>> 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.
>>> no. You still don't understand my concern. I don't care that the
>>> information goes first on the dev ml. I'm concerned to have a neutral
>>> way to discuss at the time you want, not depending of a manual
>>> synchronisation. Since you can't physically be online 150% of the time
>>> that's impossible anyway. Also i'm in favor of direct contacts not
>>> contacts *via* someone.
>> I get that, and I will raise that this sucks and needs automating once
>> this becomes an actual problem. For now this is a theoretical concern.
>>>>> 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
>>>>> 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.
>>> 12 months can be damageable . Let say 3 months eventually. Though this
>>> is not to us to decide.
>> 6 then.
>> Jan
>> --

View raw message