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

[Assaf Gordon]

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 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):
   https://savannah.gnu.org/support/?106581

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:
    http://savannah.gnu.org/maintenance/HowToBecomeASavannahHacker/
    (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 
patches,
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 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.

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 ( 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:
   http://savannah.gnu.org/maintenance/SavannahServices/
   http://savannah.gnu.org/maintenance/SavannahArchitecture/
   http://savannah.gnu.org/maintenance/SavannahInternals/

> If I could rewrite Savannah's interface from scratch (and had web design
> skills), I would adopt OpenProject's ([6]), minus the JavaScript
> requirement.
[...]
> 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:
    http://savannah.gnu.org/maintenance/HowToBecomeASavannahHacker/
    (under "Working on the Savannah Website")

    http://savannah.gnu.org/maintenance/SavannahHackingIdeas/

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

Donating money to the FSF will also greatly help:
   https://my.fsf.org/donate

> [...] 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 
Savannah.
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:
    http://www.gnu.org/software/coreutils/coreutils.html
    http://www.gnu.org/software/emacs/
    http://www.gnu.org/software/tar/

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 
lacking.
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