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