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

[Andrea Arcangeli]

On Sat, Jan 14, 2006 at 10:13:56PM -0500, glyph at divmod.com wrote:
> Epsilon only contains bug-fixes that have already been contributed to 
> Twisted.  It only installs them if a package specifically requires a fix.  
> If Nevow wants to require unreleased fixes to Twisted, Epsilon would be one 
> way to go about it; rather than requiring users to upgrade to unreleased 
> versions of Twisted so that we can do a release of Nevow, Nevow's 
> developers can simply drop in the appropriate Twisted fix, and then use it. 
> The fix will only be enabled when it is requested, so it will not conflict 
> with other libraries which depend on the buggy behavior unless they are 
> being used by the same process.

What you're saying is that if there's a twisted bug and not fixed by
epsilon either, instead of upgrading twisted to fix the bug, you require
upgrading epsilon. If there's a bug you have to upgrade something
anyway, why don't you upgrade the buggy thing in the first place?

What you're missing is that your epsilon hotfix.py grand plan works only
today, 15 Jan 2006, because you release epsilon today, and you know the
bugs that happened in the last years, so today epsilon can fix all those
bugs without upgrading twisted. But on 15 Jan 2007 you will have to
upgrade epsilon, or do you plan to ship an epsilon2 package to plug on
top of epsilon1?

If the bug exists you should release an hotfix release of twisted,
stable releases exists in all projects out there, so _all_ apps
including CPUShare and KLive will be fixed, not just Nevow thanks to the
suggested epsilon dependency.

> If such a thing were necessary, Nevow could quite easily depend upon it.  
> That probably will not be a requirement until Nevow is mature enough to 
> have a 1.0 release, however.

I hope it'll never be a requirement ;)

> One way to avoid this would be for you to volunteer to be the release 
> manager of Twisted and be very responsive to release requests.  If 
> arbitrary Divmod project releases could easily depend upon Twisted releases 
> being made very quickly, a work-around package would be less important.

This is exactly the point. When a bug happens, there should be a stable
release of twisted. As said above all twisted apps needs this, not just
Nevow.

If there is need of a release manager for hotfix releases, I can offer
my help. But why don't we use this algorithm instead?

	twisted_stable_release_manager = epsilon_release_manager
	del epsilon_release_manager
	del epsilon

My primary interest is that twisted/nevow is healty and successful
project. Even if I had no 20k lines invested already into twisted and I
had to start from scratch, I would be still starting with twisted a
second time since it seems the easiest of all to write code. Even
bittorrent uses twisted core these days (but I assume you all know this
already).

Also note: while currently twisted is the best choice, I'm not religious
about python/twisted, and I can't predict the load over time, if python
will be too slow I may be forced to rewrite the whole thing in C++ but
to kickstart the thing python is much faster.

> we don't employ Chris.  We can't call him up and say, "do a release now, 
> becuase it is your job".  Maybe Twisted can't release the appropriate 
> subproject for some reason - a release goal hasn't been met, several 
> buildslaves have been taken offline for days' worth of maintenance - 
> whatever.

Note the problem you mention is the same for all open source projects
out there. The only solution for you is to fork the project when you get
the request from your customer, and to ship a divmod-twisted package. If
you use the delta patch like yast update does, the hotfixes will be tiny. 

I don't really see the problem you're talking about, assume you need to
ship mozilla to your customer, are you going to get a certain release of
mozilla to suit you schedule? Of course not, the open source projects
goes with their schedule, this is the norm.

Note however that the stable branches exists exactly so you can apply
the hotfix without having to test with buildslaves etc... Assume that
there is a major and obvious security hole, the one liner fix will be
obvious to everyone, so releasing a new stable twisted would be required
quickly. You _can't_ fix a major security hole with epsilon, or only nevow
will be safe.

If the kernel is released in days when a hotfix arrives, you must be
able to do that with twisted too.

> Before we get to apt or yast or whatever, we have to produce upstream 
> releases.  Producing an upstream release of Twisted is substantially more 
> work than producing an upstream release of a Divmod product, even Nevow.  
> Producing a release of Epsilon requires at most an hour or two of work.

Then fix the process of releasing a stable release of twisted. You see
the frequency that kernel releases are released? The y in 2.6.x.y
changes at rapid peace. You don't need to make big PR every time a
release is issued. That's a stable cycle exactly for this kind of
hotfixes. Checking the patch into the stable branch and launching a
command that creates and uploads the tarball is more than enough. I
don't see the problem, you must be prepared for this already in case of
security issues.

> You may be confused by the fact that Nevow discussion takes place on this 
> list, because it is a popular Twisted-capable web framework.  However:  go 
> to nevow.com.  Where does that take you?  What is the *first word* on the 
> page that you see?  What is the SVN URL for Nevow?  Are you detecting a 
> theme yet?
> 
> I really appreciate the open-source contributions from the Nevow community. 
> They have been substantial, and it certainly wouldn't be the product it is 
> today if we hadn't had them.  However, its full name is "*Divmod* Nevow".  
> Divmod has paid for every stage of its development, and written the vast 
> majority of its code (>80%).  Its primary author, Donovan Preston, stopped 
> working on it when he left Divmod, and maintenance has been taken over by 
> JP Calderone, who currently works -- surprise, surprise -- at Divmod.

The thing is quite simple, if Divmod customize nevow for its own
commercial interest adding dependencies on epsilon package to make life
easier for its customers (and I never said you don't have any right to
do that), then the community as well has the right to take nevow and
fork and develop it in a way that is more long term oriented without
silly dependencies that can scare away users.

> Yeah, the story behind that is kind of weird.  twistedmatrix.com is an 
> older domain, that I bought when I was 16 or so, and *everybody* was 
> registering .com names.  Domain squatters have long since purchased .org 
> and .net.  When Divmod was registered, we got the .org for our open-source 
> works and the .com for our commercial service.

Ah ok ;)

> None of this fixes the release-management problem I've described 
> repeatedly, which doesn't seem to concern you at all.  I understand that 
> you don't use a package manager, or even downloaded tarballs of released 
> version of projects, but that is an extreme minority position.  In many 
> companies where it is allowed to use open source at all, it is *strictly* 
> disallowed to use un-released and/or unpackaged versions on production 
> machines.

Yep and this is why you must be already able to make quick releases of
twisted, to solve any security hotfix problem. Furthermore if the bug is
minor, you should fork the thing and ship your customized version to
your customers like if it's mozilla.

> Not true.  Moe, for example, has checkin rights to Divmod and not Twisted.  

Ok one person has not access rights to twistedmatrix.com SVN, but I
assume it would be ok to give him checkin rights into the
twistedmatrix.com Nevow repository right? It can't be such a big deal.

> There are plenty of people who have commit access to Twisted who would not 
> even want to work on any Divmod projects.  I certainly don't think that all 

I was suggesting moving stuff from divmod.org to twistedmatrix.com, so
that's not an issue.

> If you want this kind of ease, help us produce eggs, or debs, or improve 
> our installation instructions.  I thought this thread began as a helpful 
> (albeit misguided) suggestion, but it is quickly devolving into a simple 
> whine: "why doesn't divmod do everything the way I want?"

It now turned into: why don't we copy Nevow into twistedmatrix.com.

> Let's say you did convince everyone involved that this was a really good 
> idea, and the various repositories should be merged.  It is still probably 
> several weeks of work to do this.  What about bugtrackers?  What about 
> repository performance (doubling the size of the repository in one commit 
> is not going to make SVN happy).  What about merge history on outstanding 
> branches?

I'd be ok to even risk losing all of it, I keep lots of backups too for
the exact reason that if you delete nevow I won't risk losing it.
Losing the history would be annoying but it's by far not the most
important thing if compared to the code itself.

> Twisted already includes a zope.interface tarball in sumo releases.  The 
> expectation is that if you are working from the repository, you should not 
> be doing setup.py install anyway - that pollutes your installed directory 
> with an unspecified development version.

My build script are not polluting anything, but I know that's an
uncommon way of updating... ;)

> Your main point, that people are in "violent agreement" with, is that 
> obstacles to installation should be removed.  The Divmod team agrees with 

Ok great ;). This is by far the most important thing.

> with Divmod) have already disagreed with you publicly.  They do not seem to 
> have a problem with our "behavior".

You're right to admit there is a "behaviour", if they're fine with it
good, I'm not and I find attractive to exercise the rights you given me
by releasing nevow open source.

> What started this discussion was MG objecting to an unnecessary dependency. 

Things got worse from my part when you started describing what epsilon
does.

> dependency on a project which is small on disk is the WORST thing that ANY 
> project can do EVER.  That is simply not true.  You are objecting to a 

Every case is a bit different, but trust me it would be more acceptable
for me to have a dependency on something useful, not an hotfix package
that only works today because you know the bugs of the past, and then
it'll require an upgrade too next year (but by that time you'll have
epsilon2 ready anyway).