Thread: [oll-user] Next iteration on the way to paradise ...

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi,

after my first experiences with SourceForge I have to say I'm quite 
disappointed and will soon revert the move to that platform:
- The web site is rather clumsy and unresponsive
- The product is quite buggy and they are struggling with permission issues:
   - I couldn't delete a subproject, and a staff member with higher 
permission had to do that
   - Updating things often isn't propagated to the site
     (for example reordering the menu or removing entries from it often 
didn't work)
   - Project descriptions and/or feature list weren't displayed on the 
project main page
- Code hosting is by far inferior to other providers
   - The commit browser isn't really interesting - especially compared 
to GitHub's network graph
   - Pull requests are possible (although still undocumented!) but very 
awkward:
     You can't process them online but have to pull them first before 
you can see their content.
     One of my two trials didn't even work at all because Git refused to 
merge
     (not because of merge conflicts but because what I got to fetch was 
"nothing we can merge") ...

That last point was the show-stopper for me. Pull requests are really 
indispensable for a project like this: I want as many contributors as 
possible, but of course we can't give everybody push access.

So we'll have to change our options once more.
It seems we won't get a 'one-stop-shop' now, but OK, who has it? 
(LilyPond doesn't, for example)
I will make a few announcements and ask for voting on a few open 
decisions now:

Code hosting
========
As the main provider for hosting I see GitHub and BitBucket.
While their offerings are quite similar I decided to go for GitHub for 
the following reasons:
- The web experience is even better with GitHub (esp. for the network graph)
- you can actually edit files through the web interface (which is handy 
for README files, for example)
- The issue tracker is slightly more configurable (although I don't like 
it too much)
- You can actually edit pull requests online (although BitBucket's 
implementation is very good too)
- See below for the project website issue

Web site
========
Other than SourceForge, both competitors only offer static web sites to 
be served.
But GitHub offers a tool called Jekyll which seems a good alternative.
Jekyll is a Ruby script that takes a set of templates and content files 
(similar to stacey) and renders them into a static web site before 
pushing it to a web server. Which of course results in fast, reliable 
and secure web sites.
Of course GitHub offers that with special features: The project web site 
resides in a dedicated Git repository, and whenever something is pushed 
to the master branch, Jekyll processes the content on the GitHub server, 
so from the point of view of a content author it actually behaves like a 
server-side CMS.
This is far better than the handling on SourceForge, where one has to 
upload the web content separately.
The only drawback I see so far is that Jekyll is _very_ blog-centric, so 
it may become somewhat awkward to talk it into creating a traditional 
web site with hierarchical navigation.

The domain redirect will work as with SourceForge, i.e. the web site 
will be accessible through the domain.

Issues
=======
As mentioned I don't like the GitHub issue tracker that much, but I 
think we can live with that.
Integration of Git pushes with issues is a nice thing SourceForge 
doesn't offer (although BitBucket is far more versatile in this respect).

File downloads
=======
GitHub has discontinued its download pages (because they want to 
concentrate on _code_), but one can always download a complete checked 
out branch as a zip file.
I think we can do without SourceForge's extensive download area and just 
provide our downloads as part of the Web site.
This means we'll have to include the binaries in the website repository, 
but maybe that's ok.

Or do you think we should put binary release files somewhere else (e.g. 
on a ftp server)?

Mailing list
=======
That's the only thing we won't get from GitHub.
I see two options and would like you to vote:
a) keep the SourceForge project only for the mailing list.
     I can imagine having a project page on SourceForge that just links 
to our other resources
     could be good in order to be found more easily.
    Although it _does_ imply some overhead.
b) Recreate the Google group (sorry, Jan-Peter ;-) )

Best
Urs

Thread: [oll-user] Next iteration on the way to paradise ...

Resources for LilyPond and LaTeX users writing (about) music

openlilylib-user