On 05:57 pm, gl...@twistedmatrix.com wrote:
On Aug 7, 2014, at 10:42 AM, Daniel Sank <sank.dan...@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
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
