[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Savannah-hackers-public] Savannah and the present
Re: [Savannah-hackers-public] Savannah and the present
Fri, 5 Feb 2016 05:45:24 +0000
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
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
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 kernel.org (
https://www.kernel.org/category/site-news.html ) - 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 ), 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
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.
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
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 debbugs.gnu.org, 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.
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
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.
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 (), 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
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
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 ), 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
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
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 ( http://debbugs.gnu.org/ ),
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 ftp.gnu.org) 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
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 partly due to lack of volunteers.
If you or anyone else is interested in helping with the web frontend, please
(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 
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 ( https://www.gnu.org/software/guix/ ) 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. https://github.com/coreutils/coreutils .
(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 http://savannah.gnu.org) 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 ftp.gnu.org (or its mirrors),
and viewing the code points to the gitweb/cgit servers at http://git.sv.gnu.org
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.