On Mar 18, 2013, at 15:17 , Benoit Chesneau <[email protected]> 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”. > 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’s see how this goes and revisit in 12 months. Cheers Jan -- > > - benoît > > On Sun, Mar 17, 2013 at 6:34 AM, Jan Lehnardt <[email protected]> wrote: >> >> On Mar 17, 2013, at 14:12 , Benoit Chesneau <[email protected]> wrote: >> >>> On Sun, Mar 17, 2013 at 5:50 AM, Jan Lehnardt <[email protected]> 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 >> -- >> >>
