couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [DISCUSS] Send Github new comment notifications to the dev list
Date Tue, 19 Mar 2013 13:42:52 GMT
Okay one more update.

There has been some discussion about this thread on the private@ list.
Mostly in relation to discussions around this topic that have already taken
place on other lists. Paul has very helpfully provided me with a lot of
pointers. I will read through this tonight. If there's anything that
obviously blocks us, then we deal with that.

In the mean time, Jan has informed me that he's going to work on the
technical side of this, and he's going to be doing that with Infra. So we
will know soon enough if we're blocked from that angle. Jan also told me
there will be no summary email. Please just see his last email in this
thread for more details. :)

Also, just to clarify some of the terms I have used, and why I believe we
have consensus to move forward. In my original email in this thread, I
stated that I would assume lazy consensus[1] unless anyone objects. We
received no direct objections to the proposal, so the lazy consensus
passed. Though, because of the discussion, you might also interpret the
thread as a consensus approval vote[2], in which case it also passed with
eight +1 votes and no vetos. If people are not happy with this, I can move
it to an actual majority approval[3] vote.

[1] http://www.apache.org/foundation/glossary.html#LazyConsensus
[2] http://www.apache.org/foundation/glossary.html#ConsensusApproval
[3] http://www.apache.org/foundation/glossary.html#MajorityApproval



On 19 March 2013 12:06, Noah Slater <nslater@apache.org> wrote:

> Okay, just to follow up a second time. :) In my original email, I said
> that I was looking to establish lazy consensus, which means that we don't
> need to vote, but if anyone objects, then we hash it out, and call a vote.
> There's obviously some difference of opinion here, but Benoit has clarified
> his position as -0, so as not to block us moving forward. Because nobody
> else has objected, I believe we can now move forward.
>
> If somebody wants to challenge this, please feel free to do so, and I will
> start a vote using majority consensus  (i.e. We all formally express our
> positions, and if the vote gets 3 +1 votes, and more +1 votes than -1
> votes, then consensus would have been formally established.) I am hoping we
> can avoid this though. :)
>
>
> On 19 March 2013 02:09, Jason Smith <jhs@iriscouch.com> wrote:
>
>> We fell within the expected base rate of bikeshed discussions in a public
>> forum--no big deal.
>>
>> Would it be possible to post a fresh email summarizing this thread,
>> identifying actions taken or to be taken?
>>
>>
>> On Mon, Mar 18, 2013 at 7:22 PM, Jan Lehnardt <jan@apache.org> wrote:
>>
>> >
>> > On Mar 18, 2013, at 19:19 , Benoit Chesneau <bchesneau@gmail.com>
>> wrote:
>> >
>> > > On Mon, Mar 18, 2013 at 11:06 AM, Jan Lehnardt <jan@apache.org>
>> wrote:
>> > >>
>> > >> On Mar 18, 2013, at 18:57 , Eli Stevens (Gmail) <
>> wickedgrey@gmail.com>
>> > wrote:
>> > >>
>> > >>> Every single email I get from a github pull request contains a
>> header
>> > like:
>> > >>>
>> > >>> Reply-To: mobius-medical/dev <
>> > >>> reply+p-111-0123456789abcdef-222@reply.github.com>
>> > >>>
>> > >>> And sending email to that email address causes the content of that
>> > email to
>> > >>> show up in the pull request.
>> > >>>
>> > >>> Unless public repos behave differently in this regard from private
>> ones
>> > >>> (which is what I'm using when I see these), it seems like we can
>> solve
>> > the
>> > >>> content mirroring issue *trivially*.  Nobody needs to volunteer
to
>> be
>> > >>> online 150% of the time for anything.  If someone on the ML wants
to
>> > have a
>> > >>> reply appear in the PR, then you make sure the
>> reply.github.comaddress is
>> > >>> CCd.  If you don't, then just send to the ML.
>> > >>>
>> > >>> Is all of the discussion about github PRs unaware of this current
>> > >>> email-to-PR-comment bridge, or is there some non-obvious inadequacy
>> (in
>> > >>> which case it should be spelled out)?
>> > >>
>> > >> Thanks for pointing this out, I looked at this as well, but then had
>> to
>> > write
>> > >> lengthy emails instead.
>> > >>
>> > >> My 150% number is only to illustrate the futility of this argument.
>> > >>
>> > > Are you considering my concern futile? I'm starting to be really
>> > > annoyed by the way you handle all of this. I passed sometimes to think
>> > > on that problem before posting a response to a somewhat
>> > > passive-agressive mail. I always said I preferred and I would be OK
>> > > for a solution that propose a 2-way channel. And this is not a theory
>> > > or anything (are you putting the hand on something hot before saying
>> > > it's hot?) it is a a clear concern.  If we have a solution to do this,
>> > > fine.
>> > >
>> > > Now I also said I would prefer to not use github PR at all and would
>> > > prefer a simpler workflow than multiplying the code sources. I'm
>> > > working on a mail that will propose something like this.
>> > >
>> > > - benoƮt
>> >
>> > I have replied to all of these points in the past and I made my position
>> > clear multiple times.
>> >
>> > * * *
>> >
>> > In the meantime I have contacted Infra to sort out the technical
>> details,
>> > I will report when I have more details.
>> >
>> > * * *
>> >
>> > Also in the meantime, two people have contacted me to say that they are
>> > afraid to post to dev@ because of this thread. I am fucking ashamed for
>> > us :(
>> >
>> > My apologies if my behaviour here contributed to that.
>> >
>> > * * *
>> >
>> > Everybody, this whole thread is a really poor showing of the otherwise
>> > amazing developer community around CouchDB. We value any discussion,
>> > questions and viewpoints you might have. If you have any concerns,
>> please
>> > post them to this list.
>> >
>> > Thanks
>> > Jan
>> > --
>> >
>> >
>>
>>
>> --
>> Iris Couch
>>
>
>
>
> --
> NS
>



-- 
NS

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message