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

[Jonathan Lange]

On 4/30/07, Jean-Paul Calderone <exarkun at divmod.com> wrote:
> 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.
>


Thanks for the thoughtful reply.

>From my perspective, the problem here is that strict adherence to UQDS
as described in your email is that there is no real room for
exploratory coding.

At other times, I have wanted to muck around doing some Trial
refactoring, I filed a ticket which stated my intentions with all the
clarity available, something along the lines of "muck around doing
trial refactoring". I was chastised for filing such a ticket (fair
enough, it's a lousy ticket), so I stopped working along those lines.

This time, I decided to not file a ticket, because I did not want to
prematurely problem of concisely defining my work. I am being
chastised (albeit gently) for such work, and I will probably stop
working on this code.