couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: [DISCUSS] Send Github new comment notifications to the dev list
Date Mon, 18 Mar 2013 14:17:26 GMT
Jan, you can reject anything but that doesn't mean that my argument is
invalid. And what this reject means by the way?

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

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.

- benoît

On Sun, Mar 17, 2013 at 6:34 AM, Jan Lehnardt <jan@apache.org> wrote:
>
> On Mar 17, 2013, at 14:12 , Benoit Chesneau <bchesneau@gmail.com> wrote:
>
>> On Sun, Mar 17, 2013 at 5:50 AM, Jan Lehnardt <jan@apache.org> 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
> --
>
>

Mime
View raw message