couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <dam...@apache.org>
Subject Re: Transactional _bulk_docs
Date Fri, 06 Feb 2009 16:04:51 GMT

On Feb 6, 2009, at 4:50 AM, Geir Magnusson Jr. wrote:

> I had to think about this for a day...
>
> On Feb 5, 2009, at 8:34 AM, Damien Katz wrote:
>
>>
>> On Feb 5, 2009, at 6:14 AM, Geir Magnusson Jr. wrote:
>>
>>> [sending second time, as I see my first is stuck in moderation,  
>>> and I want to reply in a timely manner]
>>>
>>> Sure, ideally.
>>>
>>> But you can't have "everyone" together at the same time on IRC,  
>>> where at the ASF, we define "everyone" to be, well, "everyone",  
>>> not you and the 4 others on the PMC.
>>>
>>> I see 579 people on the user list.  I see 294 people on the dev  
>>> list.  Just focusing on the dev list, that's 290 people, or 98.6%  
>>> of people supposedly interested in CouchDB development, that had  
>>> zero opportunity to see, review and participate in the  
>>> discussion.  Further, there's now zero chance that any future  
>>> project participant can look back to understand design decision  
>>> and philosophy.  No institutional memory.  Your goal, besides  
>>> building a great software project, should be to get the community  
>>> to the point where you can step back and do other things w/o  
>>> material effect on the community, and that requires information  
>>> like this to be somewhere accessible.
>>>
>>> And unlike Ted, I don't agree that a pointer to an IRC log is  
>>> sufficient to represent a "done decision", and he may not have  
>>> meant that anyway.  Sure, I can see a chat starting on IRC about a  
>>> topic, but I'd hope that one person would force the move from IRC  
>>> to the mail list - and at that point, maybe posting a pointer to  
>>> the *initial* discussion log would be useful.  And after that,  
>>> discussion is on the mail list.
>>>
>>> I think IRC logs are a very poor substitute to mail traffic (and  
>>> yes, I grok the downside of async communications).  A primary one  
>>> reason that they are very "in the moment" - if you are in the  
>>> conversation, it's easy to stay in, but after, when things cool  
>>> and the context of the moment isn't there, it's neigh impossible.   
>>> You also can't hit reply and quote a piece for others to see and  
>>> discuss, further broadening the discussion.
>>>
>>
>> We get a lot of value out of IRC.
>
> At a high price, IMO.  And who is "we"?

The couchdb community. Right now there are 120 people on #couchdb.

> This may hint at one of my biggest concerns here, the balkanization  
> of the PMC from the rest of the community.  I don't think I've ever  
> seen a project where the dividing line between the PMC and the rest  
> of the community was so often and brightly drawn.

Please tell me more about this brightly drawn line. We should get rid  
of it.

> The PMC is a *legal* mechanism through with decisions and governance  
> of the project become decisions of the ASF as a corporation.  IMO  
> (and this is only my personal opinion), the wall between PMC and  
> committers, or PMC and community should be as invisible as  
> possible.  Yes, only the PMCs votes are binding.  But if you want to  
> build a broad, deep and sustaining community, people need to feel  
> they have a voice, even if it's advisory only.
>
>> We are going to discuss this on the ML. I was waiting until I got  
>> the patch work to talk about all the implications and how we'd set  
>> the flags and modes of operation and all the implications. The code  
>> is going to get more powerful, the plan is for the feature to go  
>> away, not the capability. If we decided the feature was too  
>> important, we'll put it back. But as it stands, the changes to the  
>> code that I'm making now all need to be made regardless if we  
>> change the feature or not.
>
> I hope you can understand my confusion over this, as this is what I  
> was reading yesterday :
>
> On Feb 4, 2009, at 9:13 PM, Damien Katz wrote:
>
>> Geir, there was a decision made by the PMCs to change the  
>> transaction model to support partitioned databases. It is a change  
>> I am currently working on.
>
>
>
> So what's going to be discussed?  flags?  I can sorta guess how this  
> is going to play out - you're going to do the work, commit the code,  
> and then ask for a salute from a PMC that from my POV tends to  
> salute.  At that point, people won't dare speak up since they'll  
> feel like it's futile.

So lets see, the PMC doesn't listen to the community and they only do  
what I say. Any other choice words for my fellow project members?

>
>
> And I apologize in advance to any other PMC member that is insulted  
> by what I wrote - I intend no offense - but it *is* my perception  
> (and I'm fairly sure the perception of others) that is how things  
> work at the moment.

I did find it insulting, and I assume the rest of the project has as  
well. But I accept you apology and I hope you avoid being insulting in  
the future.

> There's a comment later in this thread where Chris describes his  
> role as ... well, for lack of better words, your handler, to shield  
> you from the community.  Things like that feed my perception.  More  
> on that later.
>
> I have an idea :
>
> 1) Stop coding.

No. The changes I am making need to be made regardless. They encompass  
much more than just the transaction change.

And furthermore, I don't need to explain myself to the general public  
before I write code. To suggest I must get community support before  
firing up my editor is silly.

>
> 2) Write down a summary of the change you want to make, and why.

ok. I'll have something written next week. As planned.


> 3) Invite and engage discussion, and give serious consideration to  
> any that isn't supportive.  I think people mean well.
ok. As Planned.

>
> 4) In the end, when everyone has had their say, do what you feel is  
> best.
ok. As Planned.

>
> 5) If someone still objects, then decide if that opinion matters.

ok. As Planned.

>
>
> And when I say "matters", I don't mean only in the "Is the vote  
> binding?" sense.  You'll have to take into account technical  
> relevance, how this affects the perception of the project as a  
> whole, etc.  It's complicated, but anything involving humans tends  
> to be. :)
>

Thank you for the advice. We've never said to anyone that these  
decisions where final. Ever. Ever. Ever. I fact, we explicitly talked  
about provisions to reverse it, to leave in the capability in case we  
must keep the feature in.


> At that point, you could continue as you want, reverse direction,  
> discuss more, call for a vote, etc.  But it's not clear that you're  
> anywhere near that point already.
>
> To be fair, I've found you to be open - e.g. our discussion  
> regarding the reality around durability - which is why I'm spending  
> the time proposing this.

>

Then why are you being so combative and insulting to our team? We have  
been nothing but open and willing to work with people. The only  
complaint is that I didn't run some stuff over the mailing list before  
writing code. I haven't checked in anything yet, and I won't until  
we've had more discussion, review and testing. This problem is a non- 
issue,

-Damien

>
>>
>>
>>> What got me engaged on this wasn't the decision itself (only  
>>> because it was a secret decision), but -like Ted - the mode of  
>>> operation.  It seemed that a very dedicated, engaged and  
>>> interested community member had to privately petition the PMC for  
>>> redress on a technical decision that none of us had any awareness  
>>> of, nor a chance to review.  And IMO, from a guy that probably  
>>> should be a committer and PMC member to boot!
>>
>> He mailed us privately. Now he's mailed us publicly.
>>
>> Any discussion about Antony being involved with the project should  
>> probably be private.
>
> Indeed!  I'm on the list.
>
> geir
>
>>
>>
>> -Damien
>>
>>>
>>>
>>> (By the way - from my count, not all PMC members are even on the  
>>> PMC's private@ list, so I have *no clue* where project private  
>>> discussion - like new committer candidates - are even discussed....)
>>>
>>> geir
>>>
>>> On Feb 5, 2009, at 2:11 AM, Damien Katz wrote:
>>>
>>>> Ideally yes, but real time communication with everyone together  
>>>> is damn useful.
>>>>
>>>> -Damien
>>>>
>>>> On Feb 5, 2009, at 2:07 AM, Ted Leung wrote:
>>>>
>>>>> Uh, project decisions are supposed to be made in the public  
>>>>> mailing lists...
>>>>>
>>>>> Ted
>>>>>
>>>>> On Feb 4, 2009, at 6:51 PM, Damien Katz wrote:
>>>>>
>>>>>> This decision was discussed and made on IRC.
>>>>>>
>>>>>> -Damien
>>>>>>
>>>>>> On Feb 4, 2009, at 9:26 PM, Geir Magnusson Jr. wrote:
>>>>>>
>>>>>>> can you point me to a reference to where the PMC made this  
>>>>>>> decision?
>>>>>>>
>>>>>>> I'm interested in the subject for it's own sake, and I'm also
 
>>>>>>> interested in figuring out where decisions are made in this 

>>>>>>> project, since I didn't see this one go by on a mail list.
>>>>>>>
>>>>>>> geir
>>>>>>>
>>>>>>> On Feb 4, 2009, at 9:13 PM, Damien Katz wrote:
>>>>>>>
>>>>>>>> Geir, there was a decision made by the PMCs to change the
 
>>>>>>>> transaction model to support partitioned databases. It is
a  
>>>>>>>> change I am currently working on.
>>>>>>>>
>>>>>>>> -Damien
>>>>>>>>
>>>>>>>> On Feb 4, 2009, at 8:46 PM, Geir Magnusson Jr. wrote:
>>>>>>>>
>>>>>>>>> and original question #2?
>>>>>>>>>
>>>>>>>>> geir
>>>>>>>>>
>>>>>>>>> On Feb 4, 2009, at 8:38 PM, Antony Blakey wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 05/02/2009, at 12:02 PM, Geir Magnusson Jr. wrote:
>>>>>>>>>>
>>>>>>>>>>> 1) where is this being forwarded from ?
>>>>>>>>>>
>>>>>>>>>> I sent it to the PMC.
>>>>>>>>>>
>>>>>>>>>> Antony Blakey
>>>>>>>>>> -------------
>>>>>>>>>> CTO, Linkuistics Pty Ltd
>>>>>>>>>> Ph: 0438 840 787
>>>>>>>>>>
>>>>>>>>>> A Buddhist walks up to a hot-dog stand and says,
"Make me  
>>>>>>>>>> one with everything". He then pays the vendor and
asks for  
>>>>>>>>>> change. The vendor says, "Change comes from within".
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>


Mime
View raw message