[Twisted-web] Re: [Nevow-commits] r3904 - server-side (fragment)

[glyph at divmod.com]

On Sat, 14 Jan 2006 13:57:56 +0100, Andrea Arcangeli <andrea at cpushare.com> wrote:
>On Fri, Jan 13, 2006 at 01:35:47PM -0500, glyph at divmod.com wrote:

>> If twisted.flow had been written by Divmod, for Divmod projects, that's
>> where it would be.  Since it was written by a Twisted developer, before

>Note that this is a total nosense and it's probably the source of the
>mess that is happening. I didn't quote it last night (I wanted to sleep
>on it first ;), but this seems the source of the problems, and those
>problems now extended to the point of infecting the nevow trunk.

What problems?  Nobody sees any problems but you, and the only manifestation of said problems is that you and I are generating a lot of noise on this mailing list.  :)

>Here you say that you can't move twisted into divmod.org, but then you
>say that whatever thing was written by divmod - like if it were divmod
>creating twisted.flow -  then twisted.flow would go into divmod.org
>instead of twistedmatrix.com.

And that would have been correct.  Nothing in Twisted uses twisted.flow, so it is a good thing that it is removed :-).

>So what, let's assume everybody did this with every project out there,
>can you imagine the mess.

That *is* what everybody does with every project out there.  You don't have to imagine the mess, you can *visit* the mess at http://sourceforge.net/

You could argue that sometimes people start new projects when they should contribute to an existing one, but there is another side to that coin: all the people starting separate projects reduce the management overhead of the existing ones.  Also, this is not the case with Divmod - as just one example, JP Calderone shoulders a huge amount of Twisted's maintenance and he works with Divmod.  If we had any resources to spare, we would all do more of this during work time :).

>Think if IBM were to keep all their kernel drivers into ibm.com instead
>of sending them upstream...

The kernel is the exception, not the rule, and there are probably a lot of ways the technology could improved (either at the version-control layer or within the kernel itself) to allow the groups which contributed various drivers to maintain them separately.  This is the rule in the open source world, since, for example, Gaim is not part of GNOME.  Even so, in kernel land, many projects *are* maintained separately, and only periodically merged.   Some examples off the top of my head (and I am certainly no kernel expert):

http://linuxwacom.sourceforge.net/ http://www.netfilter.org/ http://secure.netroedge.com/~lm78/ http://www.bluez.org/

You could think of Linux in this way as functioning more as a distribution than as a project of its own.  In that sense, if Twisted and Nevow could be distributed in up-to-date versions by Debian, IBM:Drivers:Linux:::Divmod:Nevow:Debian

>I tell you this beahaviour of yours above is a recipe for disaster, as a
>CTO you should know this without me having to tell you. So please
>realize the huge mistake and fix this. A successful product doesn't only
>require good code, it also requires a perception of solidity, and a
>dependency on a few bytes package won't give it. Note that many totally
>dislike the mess of dependencies of projects like gnome too.

As a CTO I should also know that contributing anything to the open source community is a huge waste of time.  Luckily I do not believe what people tell me unless they have good reasons :).

The perception of solidity that you want could more easily be provided by better test coverage and removing certain fragile pieces of the API (such as WovenContext, which we have been talking about removing for months) than by obscure future guarantees of not depending on certain code.  Want to write some tests instead of some flames? :)

>When you touch nevow trunk you must do it with twistedmatrix open source
>mind, not with divmod mind.

"When you post about Divmod projects, you must do it with Divmod mind, not with CPUShare mind."

Please stop telling me what to do because I "must" or I am "allowed".  If I had the feeling that you were saying this with the backing of a large community, I might be more inclined to do something about it, but I would still be unhappy with your tone.  Considering that you are a lone voice though, you are going to have to give me convincing facts and specific suggestions, or I will happily ignore you.

Frankly, I don't even understand why *you* think this is such a serious problem.  What's under discussion here is how you think that *one day possibly* introducing a dependency on Epsilon for a *good reason* is a huge problem that we all need to think about fixing right now.

>The fix is to add this simple rule (that I thought was obvious) to your
>divmod guidelines: the decision of where to put what, must not be in
>function of who wrote it. It's a one line rule, it collides with your
>claim at the top and I understand this sometime can go against your

Not only do I not think what you are saying is obvious, it is so obviously wrong that it strains my imagination to even consider how you might think so.  Who writes things is a very important consideration, possibly even the only real reason, for where they go.  There are people who contribute to more than one place, and the Divmod team does check quite a bit of code into Twisted, but there are rarely projects that accept from more than one source, almost by definition.

FreeBSD developers, for example, do not put much stuff into the Linux kernel.  I have not received any patches from Django developers for Nevow, even though they certainly have expertise that could be applied to it - neither have I written any patches for SQLObject, despite the fact that I know some things about ORMs in Python.  The first version of Twisted could easily have gone into Python and replaced asyncore, but I am not a Python core developer and I was the one writing it.

>commecial interest, but I think you've a bigger interest to defend that
>is to leave twisted/nevow a community effort.

If there is ever a general outcry in either of these communities that something we have *actually done* is really wrong, I can promise you that we will consider it.  One developer's deployment preferences do not constitute a "general outcry".