De Icaza "civil and polite"?

In response to RMS: De Icaza Traitor to Free Software Community:

Kudos to De Icaza for remaining civil and polite despite such a low blow from RMS.

While I certainly think that RMS went a little too far in his comments, it's unfair to overlook the highly personal attack with which De Icaza opens his post:

I want to say that God loves all creatures. From the formidable elephant to the tiniest ant. And that includes Richard Stallman.

I'm not familiar with De Icaza's religion, but it's common knowledge in the Free Software community that RMS is an atheist. Many atheists, especially in the United States, find proselytizing of the "God loves you" sort to be highly insulting. In this situation, especially, it feels like De Icaza is trying to evoke the popular image among the religious of the Bitter Atheist, the sort who really believes in god but hates him so pretends he doesn't exist, vs. the Friendly, Reasonable Theist, who is just trying to get the Bitter Atheist to see the truth.

Furthermore, the widely quoted comments from RMS were made in the setting of a spoken forum. Once the words are out of your mouth, there's no Backspace key to take them back, and we already know that RMS can get quite emotional about issues affecting the Free Software community.

But De Icaza had a chance to consider his response carefully (he was, after all, writing a blog entry), and he opted to publicly, albeit indirectly and with some subtlety, attack RMS's lack of religion. Being polite doesn't make you right, but even if it did, who was really being less "constructive and civil" here?

I wanna make an IDE for my language‽

"Why not write an Eclipse plugin instead? That way you can leverage an existing, well-known IDE while introducing features needed for your language."

"Good idea!"

You scrabble up the face of Eclipse Mountain knowing that when you reach the top you will be much higher than you could have gotten in the same amount of time without it.

You finally reach the top and oh my god it's one of those funnel water slides you're going around and around spiraling down oof fell through the hole in the center, falling falling what's that down there is that red—

Recursive directory creation API

Right way: succeed if directory exists. Examples: GNU Coreutils, Common Lisp.

Wrong way: fail if directory exists. Example: Python.

I should think that if a recursive directory creator thinks that failure in the case of existence of the final directory in the series is an option, it should also fail if the parent exists, and so on, proceeding to fail in the case of the existence of ‘/’, when all else doesn't fail.

PLIP #42: Remove Zope dependency

Manage requests, persistence, and scaling directly within Plone, eliminating a system that is confusing to first-time users

Proposed by
Stephen Compall

Seconded by
None as yet

Proposal type
Core

State
being-discussed

Motivation

A frequent complaint of newcomers to Plone deployment and development is the use of Zope to provide features such as HTTP request handling, object persistence, transactional safety, and load sharing. It is difficult enough to learn one large system at a time; by requiring the learning of two large systems, Plone effectively makes things twice as hard for newcomers. It is also inconvenient for users to have to install Python 2.4 when they frequently already have 2.5 or 2.6 installed.

Plone is now large enough that it should be able to stand on its own, without Zope.

Assumptions

This proposal suggests the removal of Zope only. Others have suggested, variously:

• Removal of Python dependency;
• Allow extension via CLR;
• Allow extension via PHP;
• Portability to abacuses.
  

This proposal only concerns Zope.

Proposal & Implementation

By removing all imports of Zope Python packages and fixing any problems indicated by unit and user testing, and possibly replacing remaining functionality that Zope might provide with Plone-specific packages, we can remove Zope entirely from future buildouts and installations. A wider variety of Python versions may also be used.

Deliverables

Included are:

• New versions of all Plone packages with Zope dependencies removed.
• A new paster to replace ZopeSkel, with a buildout skeleton that does not include the zope2instance recipe.
• New Plone packages as needed to replace remaining Zope functionality that might be convenient.
• Replacement of all mention of "products", a decidedly Zope-centric term, with "goodies".
  

Risks

Users of add-on packages that have not been ported to become goodie-compliant by removing their Zope dependencies may have trouble working with a Plone implementing this proposal, and make take a little time to port.

To mitigate this inconvenience, we might offer a compatibility package, Nine, which provides features of Zope 2 and 3 for Plone 4 add-on goodies that need them.

Participants

The maintainers of the respective packages in Plone Core are responsible for removing the Zope dependencies in their packages. Zope dependencies will be removed from Collective and third-party add-ons as a matter of course.

Progress

Many existing utilities do not call Zope methods and functions at all, and thus may be considered already ported. Many references to Zope do remain in Plone, however.

svn-upgrade on a Bazaar Loom

I maintain modifications of Trac, a Subversion project, as a Bazaar Loom. The bottom thread mirrors the 0.11-stable branch using bzr-svn, with features built purely in Bazaar revisions on top.

When I upgraded bzr-svn once, the Subversion storage format changed incompatibly, meaning I could no longer track Subversion without rebasing my Loom. Here is how I did it:

1. Make sure the loom is fully forward-merged so that every thread's head is a parent of the top thread. Revisions you miss won't be converted correctly.


2. Make sure you are on the top thread. svn-upgrade only converts the HEAD and its parents, so if you aren't, the conversion will miss higher threads.


3. bzr record the loom if there are changes.


4. Copy or branch the loom to a backup, in case you mess up.


5. In the Loom directory, run bzr svn-upgrade --idmap-file=../myproj.idmap http://svn.edgewall.org/repos/trac/. The idmap is for your later reference so you can fix up the loom head references, and you can choose where you want to save it. Unless you have parent_location set in .bzr/branch/branch.conf to the actual Subversion branch, you must specify the URL to the repository. This should be some parent directory of the Subversion branch URL, and is usually the one that contains the branches, tags, and trunk subdirectories.


6. That should spend a bunch of time accessing the network.



7. Now you need to fix up the .bzr/branch/last-loom file. This is a plain text file, and opening it you'll immediately see why we saved an idmap.
   
   The first line is very obviously the Loom file format, which should be "Loom current 1". The second points to the recorded loom, which you can leave alone, because we'll just be fixing where the threads point.
   
   Each line following is info about a thread, bottom-thread-first (completely counterintuitively, but there you are). The last revision at time of loom-record comes before " : ", the current revision after, and of course the thread name.
   
   Note that the top (bottom-of-file) thread is a little different. Unlike every other line, the revision ID after " : " is slightly different from the one before. That's because svn-upgrade successfully communicated to loom that the HEAD revision is now the rebased one. It should give you a hint as to how to fix the others.



8. Looking at the idmap file, you'll quickly see a pattern. Revisions that come from Subversion have their prefixes changed, from "svn-v3-trunk0:" to "svn-v4:", and "%2F" changed to "/" in my case. Non-Subversion revisions simply have "-svn4-upgrade" appended. The whole point is for the svn-upgrade to be trivially repeatable by multiple branch owners, so either memorize the pattern, or keep this file handy.


9. Back in last-loom, change the revids after the " : " according to the map. If your loom is like mine, with a Subversion revision as the basis and the rest in pure Bazaar, this means changing "svn-v3-trunk0" to "svn-v4" and any instances of "%2F" to "/" for the bottom thread (first in last-loom file), and adding the "-svn4-upgrade" to the rest. Do not change the revid before the " : ". Do not change line 2. Do not change the last line, because it was fixed already.


10. Move down through the loom looking for failures of bzr log --show-ids -l1, which should print out the revids you just wrote into the loom. If there are failures, you probably messed up a replacement revision; check your idmap file again.


11. Once you've verified everything, move back to the top thread with bzr switch and record the loom.

What about inter-Loom activity?

The whole point of repeatability in svn-upgrade is to allow independent upgrades to be shared between. So if you have people with divergent looms, simply using svn-upgrade on all of them will make the threads compatible.

This says nothing about whole-loom merging, though. Loom-recording, even between two equal looms, will create divergent loom records. I've never tried loom merging, so you may have to rough it by doing thread-only merging until everyone is synced up again.