couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: [DISCUSS] Send Github new comment notifications to the dev list
Date Mon, 18 Mar 2013 14:46:05 GMT
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.

>> 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?

I already explained it. neutrality is more important than supporting trends.
>> 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.

Like suggested Noah I am working on another proposal that focus on my
concern anyway. It will be online later this morning (or afternoon for

- benoît

View raw message