[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:42:52 EDT 2007


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.
>

Actually, on reflection, I'll leave that email as is. It's blunter
than I would have made it otherwise, but it accurately represents my
opinions.

However, I will note:

- I could have chosen to work on this branch offline. In which case,
the code wouldn't have been available for review at all.
- The very fact of this thread indicates that there is a window for discussion.
- Every branch has chance to be reviewed, and thus discussed.
- The time penalty of discussion is significant to me because of my timezone.
- I really do think discussion is good. However, I think that planning
as a group is not always worth the cost.

My goal is more complex than making Twisted the best software
possible. My goal is to be able to sit down and work on Twisted even
if I don't have a fully specified, fully approved goal in mind.

cheers,
jml




More information about the Twisted-Python mailing list