[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Savannah-hackers-public] Savannah and the present

From: Assaf Gordon
Subject: Re: [Savannah-hackers-public] Savannah and the present
Date: Fri, 5 Feb 2016 05:45:24 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

Hello Fabio,

Thank you for writing in detail, you raise valid points. Allow me to expand on some of them. These are my own opinions, based on helping with Savannah administration for a short while.

On 02/03/2016 07:14 AM, Fabio Pesari wrote:
Savane is old. The interface looks straight from the early 2000s at
best [...]

That is precisely the case: the web-interface is based of forked 'source-forge' code base from 2000s. It predates the modern flows of DVCS, as well as most modern web/css/js features.

Not to mention the fact that on the homepage, there are just few "news"
and some are as old as 2011, which make the site look poorly maintained,

These news are related to the Savannah website, and there aren't many news to report (most of the time that's a good sign, IMHO). Compare, for example, with the site news of ( ) - very few items, mostly technical and dating back to 2013).

and most of the "Help wanted" and "Most popular items" were posted in
the 2000s, and rarely changed since then.

For an interesting discussion about stale job posting, please read this thread (start from the bottom, first message):

I have personally contacted several package maintainers who posted these messages, and many of them explicitly requested to keep old messages.

More volunteers are always needed, if you want to help with winnowing the remaining items.

The source code isn't badly written but it generates HTML by printing it
instead of using templates (example [1]), so it's hard to modify.

As mentioned above, the code is based on old 'source-forge' PHP code. It employs the (best?) practices that were used back then - certainly not even close to what would be considered acceptable today.

More volunteers are always needed, if you want to help hack on the front-end PHP code, a starting point is described here:
    (under "Working on the Savannah Website")

And while I applaud it for offering many features which other project
hosting sites don't offer (like mailing lists and web hosting), it also
lacks some features which are considered basic nowadays, like Pull
Requests (not the same as patches), a file viewer with syntax
highlighting or showing the contents of READMEs immediately.

This, I feel, could be the starting point of a very interesting discussion, about which 'modern' features we might want in a code hosting platform, and which users are we targeting.

But it's worth taking a step back and examining what's common to these features which you refer to as 'basic': I see them all as web-based interface to existing features, or improvements to existing web-based features.

Pull-requests are exactly patches - they are simply a web-based interface to 
a web-based interface to sending them,
a web-based interface to merging them,
and a web-based interface to discussing about them.

Syntax-highlighting is web-based interface to what already exists in any respectable programmer's text editor.

Showing the README content immediately is a web-based short-cut to viewing a local file.

<personal opinion>
I have a hunch that there is a disconnect between what some (younger?) people consider modern/easy/convenient practices and what veteran users prefer.

It seems that 'modern' trends wish to put as much as possible in a web-browser ('web' is the theme of most of your points).

While 'older' trend is to do as much as possible outside the web-browser.

There are some people in our community that would argue that conceptually, 'pull-request' have nothing to do with web-based interface:,
you 'git clone' instead of web-based fork,
do 'git send-email' instead of web-based pull-requests,
merging patches then become 'git am',
discussing them is done over mailing lists by email,
syntax highlighting is done in a code editor,
and web-based usage is kept to a bare minimum, often times in a text-mode browser. For project which use, bug management is also done via email (akin to Github's web-based 'issues').

Some would even say that all of the above can be done easily from within emacs - no need for a web-browser at all.

This also keeps Javascript requirements to minimum - which is another added 
bonus for some.

I do not necessarily think that rich web-based features are not needed, but it's worth considering the fact that from the above POV, savannah already offers all the needed features for the common development workflow model. Personal anecdote: I was somewhat surprise to realize that there is a strong push-back to changes to Savannah's front webpage if they will cause it to render incorrectly on text-mode browser. That's just one example illustrating that there are more constrants at play here - it's not just about making the web interface friendlier.
</personal opinion>

And yes, I am referring to features offered by Github and Bitbucket,
which are (sadly) the most popular project hosting platforms. Of course,
Savannah shouldn't really be directly compared to them, because it
offers many more functionalities and focuses on freedom, but at the same
time, if the purpose is to get people to switch to more ethical
repositories ([2]), an effort should be made to be at least half as
appealing as those sites.

You raise an important point - Savannah is first and foremost about software freedom.

This has other implications, for example: we do not allow non-fast-forward commits, do not allow code-removal, do not allow arbitrary project creation, and do not allow project deletion - all these might be considered 'antiquated' by modern practices of other code hosting solutions.

It also means these are some hard constraints - like running the servers on free hardware - which is currently very limited.

Savannah must be conservative, to ensure we are able to provide hosting for the long term (Savannah exists since 2001, and hosts code that dates back to 1986).

It's worth mentioning with two recent events:
Gitorious closing on June 2015 after 7 years, and GoogleCode shutting down just last month, after 10 years.

Savannah's top priority is to continue to provide code hosting services for free software with the limited resources we have (limited resources also refer to the limited number of volunteers). Even if the website is ugly, working-but-ugly is better than not working.

I doubt Savannah could ever migrate to a new system but in that case,
the only choice would be Redmine (used by GNURadio, what I said about
Gitlab also applies in this case [5]), but mailing list and website
integration should be implemented from scratch anyway and I'd still
consider it ugly, but at least it would be a huge step up in usability.

I think you are mixing-up 'usability' with web-based rich websites.

Savannah for the most part is usable - in the sense that modern DVCS workflows are supported, and many projects are actively being developed. I agree that there are many possible improvements, and also agree it is not welcoming to new users who are not comfortable with non-web-based methods.

It is also worth mentioning that Savannah is architecturally different than all the other hosting solutions you've listed. These solution are usually monolithic - all their features are tightly coupled.

Savannah uses loosely-knit collection of different projects:
Mailing lists managed by with 'mailman',
Web-viewing with both gitweb and cgit (and ViewVC for CVS/SVN),
anonymous git access through git-server (and similarly, cvs,svn).
Access-control using SSH using unix-based users/groups, then passed on to git,hg,svn,cvs .
Bug tracking using DebBugs ( ),
Downloads using rsync,
and the web-interface indeed uses old ugly PHP.

There are further complications: Some aspects (like web-pages and official release to are managed by FSF admins, and savannah volunteers can not modify them - thus any code improvements there will take even longer.

To learn more about these, see:

If I could rewrite Savannah's interface from scratch (and had web design
skills), I would adopt OpenProject's ([6]), minus the JavaScript
But I think we all know that nobody is going to improve Savane - mostly
due to a lack of good designers in the free software community, not a
lack of intent.

I disagree - there are constant attempts at improving Savannah,
as there are many constraints that limit easy visible progress.

I do agree that progress is slow so far. Partly due to limited resources (FSF 
and others),
and partly due to lack of volunteers.

If you or anyone else is interested in helping with the web frontend, please
start here:
    (under "Working on the Savannah Website")

or write to address@hidden . There's a lot to be done.

Donating money to the FSF will also greatly help:

[...] and there are even GNU packages on Github [7]

Thank you for pointing this out.
Perhaps the maintainers can be convinced to move the repository back to 
Hosting primarily on Github presents other freedom related difficulties.

My biggest problem with Savannah is that its being so unwelcoming to new
contributors prevents projects like GuixSD from being more popular, and
that affects users.

The interface is indeed out-dated, and we welcome any improvements (e.g. even small patches to the front-end PHP/HTML/CSS code).

but I humbly disagree regarding the 'popularity' - I do not know what is the popularity of GuixSD, and I think the Savannah's ugliness is a minor issue in this regard:
Their website ( ) is beautifully designed,
and only few of the links or sub-pages require any interaction with the actual Savannah website. Since the code is free, nothing prevents users from mirroring the code on other platforms, and using their favorite platforms for contributions. Github (and others?) can also setup automatic mirrors to Savannah's repository, e.g. . (note that these are mirrors - the official repositories are still hosted on Savannah).

I think that it'd be better to admit a factual truth (that a very small
percentage of free software developers uses or even knows about
Savannah) and adapt rather than ignore it and drive many programmers
toward services Github by pretending Savannah can ever be relevant again.

I'll present it differently:

The savannah web-front-end (at is indeed known to few 
developers - because it is meant for package maintainers who need to 
administrate their already-hosted package on savannah.
Users who want to *use* or just occasionally contribute to the package don't 
really need to see Savannah at all.
Take for example home page for several GNU packages:

They contain all the information a casual user might need.
Asking for help usually points to the mailing-list page,
and download usually points to (or its mirrors),
and viewing the code points to the gitweb/cgit servers at 

In its current form, Savannah's web-interface (uninviting as it is) is not an equivalent with Github's project page - it is comparable to Github's project administration page - where the project's owner can modify the project's settings.

As an automatic 'front page' to a project - Savannah's interface is indeed 
Patches and improvements are welcomed.

It's also worth putting things in perspective: Savannah as a free-software hosting platform started back in 2001, when there were very few other alternatives. It is operated by volunteers, using very limited hardware resources. It can not (and doesn't try to) compete with Github/BitBucket/Gitlab's scale or features - there is simply no realistic way to acheive that given the resources we have. Savannah's relevance is not how many projects it hosts or how many new users it has, or even how easy-to-use it is.

Kind regards,
  - assaf

reply via email to

[Prev in Thread] Current Thread [Next in Thread]