[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
MediaGoblin in Debian (was: Salsa?)
From: |
Ben Sturmfels |
Subject: |
MediaGoblin in Debian (was: Salsa?) |
Date: |
Wed, 19 Feb 2020 13:22:26 +1100 |
User-agent: |
mu4e 1.2.0; emacs 26.3 |
Whoa! Thanks for pointing this out hjenkins, MediaGoblin is indeed now
packaged in Debian Experimental, which is super exciting!
https://packages.debian.org/experimental/mediagoblin
That sounds like a good suggestion regarding the Gitlab instance too.
We'll definitely add this the list of suggested options.
Regards,
Ben
On Wed, 19 Feb 2020, hjenkins wrote:
> 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.
>
> https://wiki.debian.org/Salsa
>
>
> 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
>>> agenda.
>>>
>>> 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
>>>> patch.
>>>>
>>>> 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
>>>> clean.
>>>>
>>>> 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.
Mediagoblin community meeting notes (was: MediaGoblin community meeting this weekend - 4pm Sat Feb 15 UTC-5), Ben Sturmfels, 2020/02/15