[Twisted-Python] Bloat

[Clark C. Evans]

On Mon, Apr 14, 2003 at 07:50:45AM -0400, Christopher Armstrong wrote:
| On 2003.04.14 06:48, Bob Ippolito wrote:
| > > On 2003.04.13 20:32, Glyph Lefkowitz wrote:
| > > The one I've recently decided was good is "If there's no other code in
| > > Twisted that relies on it, don't add it to CVS."
| > 
| > Which came first, the chicken or the egg?
| 
| Your analogy is broken. If you have some code that needs
| DependantMultiService, then you can check in DependantMultiService at
| the same time as your code. If it's only application-code (i.e., an
| application that is not contributed to Twisted) that needs it, leave
| it in your application for now.

This isn't a clear policy.  The primary reason... Twisted is
a framework, and not an application (right?).  Therefore, 
applications shouldn't be part of Twisted (even if they were 
contributed).  So, it really is a chicken and egg.

Perhaps a better policy, if Glyph agrees, then it is in, 
otherwise the necessary conditions for a module to be
added to twisted.* are:
   
   1. the module has three or more end-user applications, from
      at least two different authors, where one of the applications
      (how ever trivial) must be open source so that it's usefulness
      can be highlighted; and

   2. the module complies with the coding standard, and comes
      with a complete coverage test suite; and

   3. the module comes with a documentation and tutorial so
      that it's usage can be understood by others; and

   4.  the module has at least two additional (committer)
       sponsors who think that it is useful to Twisted; and

   5.  the module 'floats' around on the list for at least
       a month or so so that enough people can 'chime' in
       any objections, or so that Glyph can register a veto.


Anyway, it's kinda strict, but it would make for a good basis
for the kind of quality level that we should probably have for
new modules.

But this still doesn't solve the 'bootstrap' issue, that is,
unless the module is checked into CVS, and the documentation
is clearly available, it makes it *very* hard to find users,
and thus to meet the first requirement.

| Of course, maybe there can be exceptions to this occasionally, but I
| think any exceptions need to be thought about very hard, for the
| reasons Glyph pointed out.
| 
| Also, sandbox is appropriate for such stuff. e.g., flow.py.

Yes.  I've found that the sandbox is a great place for this,
as the code isn't officially part of twisted; but yet is in
the CVS and distributed.  

...

However, there are problems with the 'Sandbox'.  The flow.py
file is really three items:

  1.  A new flow.py file in twisted.python
  2.  A small addition to twisted.internet.defer
  3.  A small addition to twisted.enterprise.adbapi
  4.  A small addition to twisted.python.compat (already applied)

So, I'd like to see the 'Sandbox' restructured in such
a way that it takes on a 'recursive diff' shape...

  Twisted/sandbox/flow/twisted/python/flow.py
  Twisted/sandbox/flow/twisted/internet/defer.py.diff
  Twisted/sandbox/flow/twisted/enterprise/adbapi.py.difff
  Twisted/sandbox/flow/test/test_flow.py
  Twisted/sandbox/flow/doc/howto/flow.html

And then having a 'make apply_flow' which will apply the
patches and copy over what would be the result when 
adding flow to the new tree.   In this way people can go
into the sandbox and 'enable' any new additions that they
want.  

I know it's not great, but it would then be clear to 
everyone what a given proposal is.  Most modules in 
the future may not be a simple file... flow isn't, 
despite it's very small size.

Best,

Clark