[Twisted-Python] Is there pb documentation somewhere?

[exarkun at twistedmatrix.com]

On 05:57 pm, glyph at twistedmatrix.com wrote:
>
>On Aug 7, 2014, at 10:42 AM, Daniel Sank <sank.daniel at gmail.com> wrote:
>>glyph,
>>
>> > I really wish we would stop calling things "bad" and "good".
>>
>>My wording of exarkun's wording. He gave a much more detailed 
>>description of what he think's is "crazy" about pb.
>
>This was a complaint about a general trend, not about specific words. 
>Clearly exarkun gave you the impression that it is "bad", whether he 
>specifically said so or not.

I don't understand what you're saying here.

Do you want people to not describe the shortcomings of certain pieces of 
software?

Or do you want people not to conclude from such descriptions that those 
pieces of software are not the most well suited for certain 
applications?

Or do you want people to write two pages of description every time they 
want to refer to the idea that a certain piece of software isn't the 
best choice for a certain application?

Could you clarify what you think the problem here actually is?
>
>We're all intimately familiar with everything that's terrible about all 
>of our code, and we aren't shy about sharing.  I just would like it if 
>we could really lead with the details and refrain from value judgements 
>:).

In this case, it seems like that's exactly what happened.  I led with 
detail.  The value judgement of PB being "bad" (which is a gross over- 
simplification, but a convenient shorthand) came afterwards.

Jean-Paul
>> > make your own decisions about how to write your own code.
>>
>>Indeed, but gathering information from wiser folks is always a good 
>>idea, and usually best done _often_ during development :)
>
>I might quibble with "wiser" but okay.  I'm happy to provide feedback 
>earlier so I don't have to say "what is this disaster" later ;-).
>> > I'm happy to trade 2-for-1 - if you do two code reviews, I will 
>>regard it as an immediate obligation for
>> > me to review a ticket you direct me to ;).
>>
>>Deal. However, rather than direct your attention to tickets, at this 
>>stage I would rather trade reviews for discussion. I'll do two reviews 
>>and then post a few questions to this mailing list thread. Once I 
>>start actually writing patches/new code we can trade reviews for 
>>attention to tickets. Ok?
>
>I'm happy to do that.
>> > These would also be easier to land, and a couple of decades in open 
>>source has taught me that nothing
>> > motivates development activity like successful development activity 
>>;).
>>
>>Indeed. There are one or two architectural issues I want to understand 
>>before moving on to real coding. I will try to get through that asap 
>>by reviewing tickets and trading for discussion of those architectural 
>>issues.
>
>I'll try to respond to these questions regardless.  I would like to 
>help.  It's just that the reviews will create a more tangible sense of 
>commitment :).
>> > Hopefully you can make sense out of the explanations above and your 
>>own existing knowledge.
>> > Are there any other phases of the process which are confusing?
>>
>>This all makes sense now. I hadn't understood the point of the cooker, 
>>but now that you've explained it, I understand what's going on. I will 
>>transform your mailing list explanation to documentation shortly.
>
>Great, glad that helped.
>
>-glyph