[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: hjenkins
Subject: Salsa?
Date: Tue, 18 Feb 2020 17:19:45 -0800
User-agent: Roundcube Webmail/1.3.10

Mediagoblin is a Debian package now. Why not use the Gitlab instance hosted by the Debian Foundation, Salsa? It would seem to be pretty safe from vendor lock-in, there should be good support, and software licensing and hosting costs would be zero.

On 2020-02-17 09:09, Distopico Vegan wrote:
I feel the same, for me Savannah/Trac is a big barrier to new contributors

On 2020-02-15, Ben Sturmfels wrote:

Michael Lynch unfortunately won't be able to attend the meeting, but
sent through some comments for consideration (below) about his
unsatisfactory experience with the issue tracker lack of CI and
challenges with loose dependency specifications. I'll add these to the

On Sat, 15 Feb 2020, Michael Lynch wrote:

I’d like to submit some comments via email, so hopefully they’re useful for your
to consider during the meeting.

The biggest barrier to me in contributing to MediaGoblin was that
Savannah/Trac feels painfully outdated compared to Github/Gitlab/Bitbucket. I primarily work on Github, but I’ve contributed to projects on Gitlab and Bitbucket and found it an intuitive transition from Github. With Trac, I felt like I was going back to tools that I used 15 years ago, and it was a real struggle to learn how to to do something simple like search the bug tracker or contribute a

I had a lot of trouble even setting up an account on the bug tracker and then once I filed a bug, I couldn’t tell what the status is. IIRC, it was months before I received a response. It was also fairly discouraging to see a backlog of bugs
300+ issues long dating back to 2011.

The other issue that was hard for me was the lack of a CI configuration. With most projects, if I’m having trouble getting it up and running, I can check their CI to see how they’re building the project in a clean environment. I spent dozens of hours fiddling with dachary’s 4-year-old Docker configuration to get it working on the 2019 codebase. And then I basically had to throw away all that effort when MediaGoblin changed to stay ahead of the Python 2 EOL. I think you ended up replicating a lot of that effort when you updated the Dockerfiles. If there were a CI configuration so that nothing was merged into master until there was a successful build in CI, there wouldn’t be this duplication of effort or the struggle to figure out how to build MediaGoblin

One of the things I often ran into when trying to build MediaGoblin is that the pip packages would change out from under me and the process that built MediaGoblin successfully break a month later because the requirement is for, e.g., Sphinx >= 1.2.3, but then Sphinx 1.3.5 introduces a change that breaks
MediaGoblin and now the build is broken. It would be great to see
MediaGoblin switch to something like pipenv where it can specify exact
versions of pip packages that yield a successful build.

Thanks for your work on MediaGoblin! I hope the meeting is productive.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]