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:51:57 GMT

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 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.
> 12 months can be damageable . Let say 3 months eventually. Though this
> is not to us to decide.

6 then.


View raw message