This is a guest post from my friend Alexander Todorov who is a QA guru, software engineer and cloud enthusiast!

Software changes fast! Open source software even faster!

And once you start to update dependencies, libraries and frameworks it never ends… After all the testing and validation you may have done there is no guarantee that the software will keep working afterwards. This is no big deal for small and medium sized projects but becomes a full-time job for larger projects with longer life span which require constant maintenance and enhancements. I’ve seen this time and time again during my work on various projects. Even a simple Drupal based website pops up an update every couple of weeks.

OTOH back porting fixes and keeping stable APIs can be a big business. This is what Red Hat is doing for their Red Hat Enterprise Linux distribution. Nearly all changes are backwards compatible and and the software stack remains stable compared to upstream Fedora or the more upstream projects which comprise it.

Let me say that I don’t like to upgrade. Long ago I was using Debian stable on my computer. Now I use RHEL. No fancy features, no bells and whistles and more important predictable behavior wrt updates and APIs. The same approach I take when developing software. I stay away from the latest and greatest technology simply because it changes too often. I prefer mature frameworks and packages which produce new versions every six months or less frequent. This approach allows me to concentrate on writing code and getting the project done instead of plumbing bugs introduced by the latest package foo version.

All this said I have a very careful approach to upgrades, especially if I’m using an upstream package. I will first look at the changelog if any. Luckily many of the mature projects provide comprehensive changelog records. This is especially true for Perl packages. I’m looking for notices about backward incompatible changes, API breakage, security notices, major bug fixes, changes in behavior and the like. When changelog is not available there’s the commit log. I admit this is not something I usually look at but it happens once in a while. I do this for projects I’m particularly interested in or otherwise following. Doing a content diff is another possibility which usually helps you spot (if you look carefully) some API changes as well. I resort to this if I’m not able to find the upstream source repository or when it is hosted on something ancient like CVS.

Based on all of this I decide to upgrade or not. With careful planning of updates (which version, which moment of time) and testing I manage to minimize the hassle of breaking my projects and spending days fixing bugs afterwards. Instead I use the time to write some code that kicks ass (or at least I hope so).

I’m curious to know what sort of information folks do prefer to have when considering an update? Changelog vs. API diff or seething else? I personally prefer well written Changelog and full list of fixed bugs. Please cast your vote in the comments or visit the survey! Thank you!

A few weeks ago I wrote an article about the state of package management in Emacs. In that article I pointed out that on the side of package.el too much was riding on the poorly maintained Marmalade repo. Today Marmalade went dark (again) and many people are wondering what to do now. The answer is simple - start using MELPA instead.

I was thinking of starting a project similar to Marmalade to alleviate its problems, but then the MELPA project was brought to my attention. This project follows the Homebrew (unofficial OSX package manager) model of using simple GitHub collaboration to maintain and grow a bunch of build recipes. In the case of MELPA, those recipes show how to bundle upstream source packages into package.el-compliant packages. The recipes can be tested locally by package authors, and they are run hourly on the MELPA server to create an HTTP package archive that Emacs users can simply add to their 'package-archives list. As Phil Hagelberg said - there’s no reason to drag in complicated dependencies like Node for something that’s essentially a pile of static files. MELPA on the other hand is written mostly in Emacs Lisp and is thus much more comprehensible to casual Emacs hackers.

Most packages currently contained in MELPA are development snapshots, but the project maintainer Donald Curtis and Steve Purcell (aka sanityinc) are working on extending the MELPA build scripts to support stable packages, using upstream version tags.

Adding a new package to MELPA is as simple as adding a few lines of code to the pkglist file in MELPA’s source code repo:

1
2
3

(name :url "<repo url>"
 :fetcher [git|svn|darcs|wiki]
 [:files ("<file1>", ...)])

You simply have to fork the official repo, modify pkglist, send a pull request and package.el compatible packages will be built automatically for you on MELPA’s server (you can also build the packages locally to test if everything is OK with your recipes). Sure it’s not as easy as submitting a package via a web UI, but it’s a much more robust approach. It also eliminates a common problem in Marmalade - there only the original uploader (+ people selected by him) can update a package. Often the original uploaders are very hard to find…

To use MELPA with Emacs 24 (or a recent version of package.el) just add this to your .emacs (or equivalent):

1
2

(add-to-list 'package-archives
'("melpa" . "http://melpa.milkbox.net/packages/") t)

There’s a lot more info regarding MELPA on its official website and I’d rather not duplicate it here.

I would encourage package authors and users to investigate and contribute to MELPA. I’ve already submitted a bunch of packages there and rebased Emacs Prelude to use MELPA instead of Marmalade.

Together we can turn MELPA into the most extensive and robust community-supported package.el repo! Emacs users deserve one of those :-)

I’d like to apologize to everyone insulted by my previous posts. Contrary to popular belief I acknowledge EmacsWiki’s contribution to the Emacs community. Obviously many people are too fond of its current format so I doubt that it will ever change (considerably). I didn’t mean to insult anyone, I just wanted to catch your attention (which unfortunately requires harsher words from time to time) and point it in the direction of the existing problems.

For the people that weren’t happy with EmacsWiki - the ones that felt my pain and were looking for a change I present WikEmacs (pronounced wikimacs). It’s a MediaWiki powered Emacs wiki, that will try to bring to the community cleaner, leaner and more up-to-date documentation.

There are only a few guidelines for the contributors there:

• articles should be geared only towards the current and future versions of Emacs (currently 23 and 24) for maintainability’s sake.
• articles should not copy Emacs’s or extension’s official documentation - they should refer to it instead. An overview, some nice pointers, tips and links - that seems like a good article, doesn’t it?
• comments and questions should go to an article’s discussion page

File uploads are disabled on WikEmacs (but image file uploads will probably be allowed soon) - it will never host Emacs extensions of any sort.

There is a Google discussion group here for more general questions regarding the wiki.

Our goal is not to copy over the 8500 articles available at EmacsWiki. It’s to provide a good road map for new users coming to Emacs and enough helpful hints and tips for experienced users. Everyone is welcome to join our efforts.

As far as short term goals go - have a look at the outlined structure of the wiki (on its home page), pick a section that interests you and create/extend/improve it. Our content is licensed with GNU’s Free Documentation License (which is compatible with Wikipedia’s and probably EmacsWiki’s GPL2). Some nice blog articles about Emacs might be converted to wiki articles with permission from their authors. You might find pandoc useful to automatically convert articles from other formats to MediaWiki markup and mediawiki.el to edit articles on wiki from the comfort of your beloved editor.

Thanks to the people that brought us the original EmacsWiki. Thanks to everyone who supported the idea for the new wiki. Thanks in advance to all future contributors.

Some people will undoubtedly see the birth of WikEmacs as a separatist move to fraction the Emacs community. To them I’d like to say that few things in life are as productive as competition. Obviously a lot of people willing to contribute to a new wiki are unwilling to do so for EmacsWiki and vice versa. This is not a contest and there will be no winner. I wish the best of luck to EmacsWiki and its supporters. What I wish for is to give our community the best source of documentation available and the option to choose.

Prelude

Yesterday I wrote a highly controversial article about the state of the EmacsWiki and suggested a few things we can do to make things better. I got the usual batch of hate mail and some remarks on the poor quality of my English and writing style (which generally amuse me a lot). But I got much more encouraging feedback from a lot of Emacs community members. So here our story continues…

Prelude

Emacs is slowly, but firmly moving in the right direction with Emacs 24. A lot of new important features are coming, the release date is nearing, but there is something worrisome on the otherwise bright Emacs horizon. It’s a remnant from the Dark Emacs Days and it’s called EmacsWiki.

Shortly put - EmacsWiki is a blight.