Hacker News Reader

Comment by jordigh | Hacker News Reader

Argh, we really need to get Octave-Forge off SF. Octave itself is hosted on GNU servers, but all of the Octave-Forge add-on packages are in SF.

The thing is, there isn't really anything that easy to move to. No, no github, because we don't like git. We have a bunch of Mercurial repos. We could try moving them to bitbucket, but this also leaves the question of what to to do with our webpage hosting, which is currently on SF.

And no matter what we decide doing, it's all a bunch of work that nobody really wants to do.

At least when SF first approached us with their "revenue sharing" bullshit we refused. I think this means our downloads are clean so far.

View on HN

Bitbucket does static site hosting!

https://confluence.atlassian.com/display/BITBUCKET/Publishin...

Would that work for Octave-forge?

> No, no github, because we don't like git. We have a bunch of Mercurial repos.

Any particular reason?

> We could try moving them to bitbucket, but this also leaves the question of what to to do with our webpage hosting, which is currently on SF.

You could move your repositories to bitbucket but mirror the single repository for your webpage content to GitHub to use their hosting. (And if that repository is currently Mercurial, see git-cinnabar by Mike Hommey: https://github.com/glandium/git-cinnabar/ )

Or, it looks like bitbucket may have a similar feature: http://pages.bitbucket.org/

> Any particular reason?

Lots of reasons. I'd rather not go into an argument about it. It's not something that can be fixed: git is a no-go for us.

> but mirror the single repository for your webpage content to GitHub to use their hosting.

I'd rather break free, not change masters.

> I'd rather break free, not change masters.

Unless you have the volunteer army necessary to run the hosting yourself, you're going to be changing to a new master anyway. You just need to make sure it's a master you can leave at any moment.

So get a domain name and point it at GitHub Pages, and deal with git for the timebeing. At any point (either if GitHub goes bad, or someone's enthusiastic about setting up something else), you can repoint that domain name to another host, far more easily than you can change octave.sf.net to point somewhere else.

I agree that switching to octave.github.io would not actually help anything other than the immediate problem.

Well, we do have those volunteers/employees on the GNU servers. We also can pay for our own hosting. We'll probably go one of those routes.

> Unless you have the volunteer army necessary to run the hosting yourself

You don't need an army (depending on the solution). But setting up gitlab/rhodecode/indefero/srchub/Gitolite/custom scripts for a single project is kind of overkill. I've used rhodecode and whenever they released an update it would take me hours to update it. I've never been happier to fork indefero and get off of google code.

GitLab CEO here, thanks for mentioning us. We care deeply about making updating fast. Our Omnibus packages should install in 2 minutes and we recently introduced a package server to make updates just as snappy.

RhodeCode CTO, thanks for mentioning us. With our new cross-platform installer, it takes just few minutes to update running instances, and it's actually a one-liner to run the upgrade. Thanks for providing feedback !

I'm actually curious -- I understand that you have tech debt that prevents you from moving to Git, and I'm not here to tell you your concerns are irrelevant. At what point do the compromises that tech debt forces you into hamper the visibility of the project?

This seems to be a continuous problem in the open source community. As tools, maintainers, and support platforms age, how do you deal with the tech debt of keeping them supported? It's an easier calculation for a business; I'm just curious how various open source projects make these kinds of choices absent a corporate benefactor that sets direction.

> Lots of reasons. I'd rather not go into an argument about it. It's not something that can be fixed: git is a no-go for us.

I'm not interested in getting into an argument, but I'm genuinely curious what reasons remain for people preferring mercurial. At the moment, apart from "got used to the UI", the main one I know of is more "native" Windows support (without needing a Cygwin-like environment to work in). I don't know if that's an issue for your project.

> I'd rather break free, not change masters.

Fair enough. In terms of repository hosting, moving to Savannah seems like the obvious choice there then. And assuming you have people available to do the work, you could always move to gnu.org or nongnu.org, depending on your tastes and the nature of the software your directory links to.

Can't speak for anyone else but I use Mercurial because it's fast, user friendly and easy to extend with your own plugins.

> I'm genuinely curious what reasons remain for people preferring mercurial

Top-level answers here:

https://news.ycombinator.com/item?id=9467096

> moving to Savannah seems like the obvious choice there then.

The only issue is that Savannah is static hosting. We have a bit of PHP that generates one page. We might be able to replace that with Jekyll, though.

> The only issue is that Savannah is static hosting. We have a bit of PHP that generates one page. We might be able to replace that with Jekyll, though.

Does it do so from dynamic server-side data, or could you run it on each new commit and serve the result as a static page?

Yeah, we can probably do some sort of commit hook. It's not an impossible problem, just annoying.

So host your own Mercurial and HTTP servers?

Because that's about the only way to genuinely "break free".

Can you use Alioth? If you have a few Debian developers involved, it should be straightforward to set up a project and get accounts for everyone else, and it's very much like SourceForge.

https://lists.debian.org/debian-devel-announce/2003/03/msg00...

"We'll approve ... free software/documentation where a Debian developer is heavily involved (part of the core team for example). The project request should ideally be done by a Debian developer."

Alternatively, can you get your webpage hosting onto gnu.org?

We actually have quite of a good rapport with our Debian packagers... so perhaps moving to Alioth could be a possibility, even though Octave itself is not a Debian package per se.

As for GNU, the problem is that we only have static sites there. It's not a huge problem, but it might be a good solution.

Mercurial works well with github, as it can communicate with git servers. I've used github in the past with several Mercurial projects without issue.

So you can move to github and keep hg.

Have you looked into hosting from universities? I recently read about plans to move Pure Data (flow-based audio programming environment) to Oregon State University's Open Source Labs. Maybe they would be open to hosting Octave-Forge.

http://osuosl.org/services/hosting

> it's all a bunch of work that nobody really wants to do

A lot of people don't want to do things they have to do. It's a question of if you're going to wait for SF to hyjack your downloads or move preemptivly.

Also, apperently bitbucket will host static pages, I don't know if that works for you.

> At least when SF first approached us with their "revenue sharing" bullshit we refused. I think this means our downloads are clean so far.

I think it means they just get to keep more money...?

I really don't see any malicious downloads here. Do you?

http://sourceforge.net/projects/octave/files/Octave%20Forge%...

I clicked one of the legitimate downloads. The link takes you to a new page and waits a few seconds before starting the download.

The most prominent element of this page, centered just below the header, is a large bright green "Start Download" button. That button is part of an advertisement, but is blatantly designed to get the majority of its clicks from users who intended to download software from the project hosted on SF. I see it as a malicious download.

I realize you may have been referring specifically to the recent SF malware bundling, but I want to stress that this ad came up for me on my first try clicking one of those links. Ad's like that have been regular on SF for years; it's impossible to believe that they have made it a priority to prevent them. The opposite seems more likely: the page design minimizes the legitimate controls and emphasizes the scam link.

Even if I know the installer is free of opt out malware I would hesitate to send a SF link to a friend or family member. The clearest call to action they are likely to see is a malicious download impersonating the software they want.

Reply on news.ycombinator.com