[Twisted-Python] Re: [Twisted-commits] r20094 - Add a spewing decorator which stores all of the function and method calls

[Jean-Paul Calderone]

On Mon, 30 Apr 2007 12:45:59 +1000, Jonathan Lange <jml at mumak.net> wrote:
>On 4/30/07, Jean-Paul Calderone <exarkun at divmod.com> wrote:
>>On Mon, 30 Apr 2007 09:04:24 +1000, Jonathan Lange <jml at mumak.net> wrote:
>> >On 4/29/07, Jean-Paul Calderone <exarkun at divmod.com> wrote:
>> >>On Sat, 28 Apr 2007 23:37:57 -0600, Jonathan Lange
>> >><jml at wolfwood.twistedmatrix.com> wrote:
>> >> >Author: jml
>> >> >Date: Sat Apr 28 23:37:56 2007
>> >> >New Revision: 20094
>> >> >
>> >> >Modified:
>> >> >   branches/spew-decorator/twisted/python/util.py
>> >> >   branches/spew-decorator/twisted/test/test_util.py
>> >> >
>> >> >Log:
>> >> >Add a spewing decorator which stores all of the function and method 
>>calls
>> >> >within a function in a structured data object.
>> >> >
>> >>
>> >>What ticket is this associated with?
>> >
>> >None, as yet.
>>
>>I guess we should avoid having branches without tickets.  There's still the
>>sandbox to develop stuff where the direction is uncertain.
>
>What's wrong with renaming the branch to include a ticket number after
>a suitable ticket has been filed?

That operation is unsupported by the tool-chain.  But even so, for the
reasons below, it's better to start things off with a ticket, rather than
eventually introduce one.

>
>I thought the sandbox was for random bits of junk code[1] and
>Foolscap, not branches of Twisted.

More or less, yes.  Anything goes in the sandbox.  Sticking whole Twisted
branches there probably isn't the best idea on the world, but developing
functionality that actually needs to go into the Twisted tree probably also
shouldn't be undertaken without some minimal amount of planning.  That's
supposed to be part of what tickets are for (although I recognize that
sometimes they do not end up filling that role).  When I suggested the
sandbox, I really had in mind the development of some spewer-related
functionality in an independent module with little or no Twisted integration
(since from a quick look at the branch, that seemed to be what the code
looked like so far).

In case that's a little too muddled and fuzzy to make sense, here's another
angle.  A ticket serves as a point where the relevance, utility, correctness,
whatever, of a change can be discussed.  If someone is interested in some
development which is taking place, they should be able to find that point
easily and without interactive assistance from anyone.  If not, their input
may be lost or delayed until it is useless or integrating it costs more than
the ultimate payoff.

The kind of "just-in-time" ticket creation that already happens so frequently
in Twisted development is something it would be nice to move away from.  It's
completely fine to find a bug, create a ticket, and develop a fix in a brief
period of time and I don't want to discourage that.  However, and this is
really close to the heart of UQDS, for refactoring and feature enhancements,
the end result is much improved by input from other people.  Leaving a little
time between ticket creation and actual development doesn't guarantee that
any useful input will be offered by other developers, but it at least presents
the possibility.  If development starts _before_ anyone else even knows what
it's about, obviously that doesn't present any window at all.  This really
also applies to bug fixes, but I think it's at least /possible/ in some of
those cases for the necessary change to be sufficiently straightforward such
that the process works well enough with only two developers involved.

If any of this seems unreasonable, please say so and let's discuss it.  The
goal here is to make Twisted the best piece of software we can make it,
nothing else.

Jean-Paul