[Twisted-web] Re: [Nevow-commits] r3904 - server-side (fragment) nesting, and convenience descriptor generator

[Andrea Arcangeli]

On Fri, Jan 13, 2006 at 07:32:21PM +0200, Tristan Seligmann wrote:
> I don't follow this reasoning. Twisted totally depends on Python, should
> Twisted go in the Python SVN repository? Should Python go in the Twisted
> SVN repository?

It's only a matter of size.

If it wasn't because of the checkout size (both for space it takes, and
network bandwidth it requires), it could as well be all in a single SVN.
But those are significant sized project so there is different people
working on them, so splitting make administration a bit simpler.

But this is not true for epsilon, epsilon a is a few bytes, nevow is 14M
Twisted is 51M. Furthermore if epsilon contains twisted fixes needed by
divmod to become productive with old twisted version there's no chance
that the fine Nevow can depend on such a dirty package that workaround
twisted bugs.

I have one twisted-workaround lib in my app, but the whole point of this
lib is __not__ to require people to run apt get. If they require to run
apt get to install epsilon to workaround twisted bugs, then they should
have run apt get to upgrade twisted instead!!!

The whole point of a workaround-lib that fixes bugs in older twisted
releases is to avoid running apt get at all and to run the app, so to
_remove_ dependencies, not to add new ones. The only possible reason one
can want to workaround twisted bugs is to remove dependencies, there's
no chance one would ever add a epsilon dependency to install with apt to
workaround a twisted bug. In suse we even use binary diff deltas to
optimize the upgrade of big packages, just replace epsilon with a good
package manager that supports diff deltas (dunno if apt supports that).

Furthremore Nevow is a fine open source project, it's not Divmod
product. If Divmod want to customize Nevow to run on older Twisted
release they have to _fork_ it, the same way the distro fork the kernel
to customize it for their customers (i.e. freeze and stabilize 2.6 for
months, backport stric fixes etc..). You can't screw the official nevow
repository at your commercial gain. That would be something I'm against,
because I only care about the code, so if code becomes worse in any way
due divmod commercial constraints or schedule, that concerns me a lot.
I don't care where those packages are located.

However I'd prefer Twisted and Nevow to be in the same repository, be it
divmod.org or twistedmatrix.com. Apparently the .com one is the
no-profit community one, and the .org one is the commercial one, weird.
So apparently the .com one is more appropriate for nevow as well.

Then you can fork Nevow from twistedmatrix.com into divmod.org and
customize it with epsilon (or you can create a branch called divmod into
the twistedmatrix.com to add the epsilon dependency to fix bugs).

You all have checkin rights in both, so I don't see why should you care
too. If you want more stuff into divmod.org to get the credit of its
development that's fine with me, merge Twisted into divmod.org too then,
if that can help writing better code and to remove any interest in
creating divmod packages like epsilon that workaround twisted bugs.

I'm very serious when I say this, it's a matter of perception, you can't
base Nevow on a tiny package that totally depends on twisted and that
even includes twisted workarounds. Perhaps if that was a _stable_ branch
of nevow, that would be remotely acceptable. But like every open source
project out there, the _trunk_ must be aligned for the long term, and
definitely not for the short term gain of some commercial entity.

Many mistakes happened already, the obsolescence of too many apis is the
proof. I understand that one always want to learn from its own mistakes
and that you won't believe others until you scratched you head on it,
but you may as well decide to trust me and not to add silly dependencies.

The important thing is not yast2 -i or apt get that will get everything
right automaticaly, the important thing is that "python setup.py" will
just work. Requiring a "python setup.py install" of a tiny package is
silly.

Note that there is people out there that must be in violent agreement
with me. Please try to run setup.py install of zope3, does it ask for
anything? No, it just runs. Then go in src/twisted. Hey surprise,
there's twisted in there. That twisted copy takes 28M on my harddisk,
not 700K like zope.interface. To avoid a dependency they waste 28M of
HD, and yet you refuse to copy zope.interface into twisted repository
and you require an external checkout or rpm install (and I believe you're
losing users because of that, again it's a matter of perception and
solidity and self-containment of the project). Not to tell about epsilon
that is just a few bytes.

Epsilon repository should be deleted, the good parts of it must be
merged into twisted repository as twisted.epsilon or twisted.python or
whatever twisted.*, and the bug workarounds must be dropped. This is
about the community development, I don't care if you fork one of those
packages for your needs, but you can only mess in the divmod-fork, you're not
allowed to screwup the trunk developed by the community. In the
community developed one the fixes must go into mainline twisted, not in
a epsilon package!

This as long as you think a community really exists around twisted and
nevow, and that you're not the only users of twisted and nevow. Your
behaviour would be perfectly ok if Divmod was the only nevow user.

Note that I'm overall very happy with the development happening, sadly
when I have to send emails is because I think something is going wrong,
time is limited and when things goes well one doesn't need to send
emails. But as much as I like the development, sometime I see some
frightening nosenses too (new formless api wasted effort, atop wasted
effort, many twisted api going obsolete) and this epsilon thing is one
of those nosense. So this time I'm trying to help before you scratch
your head into it by yourself and before you risk to scare people away
from the project. And again, there is people who understand things that
lives very close to you, you just have to look at the zope folks merging
twisted in to avoid external checkouts to understand this, how can
explain the fact they merged twisted and they waste 28M of disk and
bandwidth when you refuse to merge a few bytes into twisted just becasue
it's not a divmod.org?

I cannot care less who gains what and what url I have to checkout, I
only care about code and there's no chance I can agree with an epsilon
dependency if it's the nevow trunk you're talking about, you're free to
add it in a nevow-divmod trunk, that's perfect!

So please trust me on this. Thanks!