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

Jonathan Lange jml at mumak.net
Mon Apr 30 04:02:38 EDT 2007


I sent this email by accident during the process of drafting. Please
ignore until I write my email in full.

On 4/30/07, Jonathan Lange <jml at mumak.net> wrote:
> 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.
>




More information about the Twisted-Python mailing list