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

[Janek W. <lem...@gm...>]

Hi,

I'm not sure about the mailing list; as for file downloads i think zipped
branches would be enough.  I agree with your other conclusions.

Janek


2013/3/28 Urs Liska <ul...@op...>

> 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
>
>
> ------------------------------------------------------------------------------
> Own the Future-Intel&reg; Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game
> on Steam. $5K grand prize plus 10 genre and skill prizes.
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> openlilylib-user mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openlilylib-user
>
-------------- next part --------------
An HTML attachment was scrubbed...