mediagoblin-devel
[Top][All Lists]
Advanced

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

Re: Fwd: Re: MediaGoblin community meeting this weekend - 4pm Sat Feb 15


From: Distopico Vegan
Subject: Re: Fwd: Re: MediaGoblin community meeting this weekend - 4pm Sat Feb 15 UTC-5
Date: Mon, 17 Feb 2020 12:09:43 -0500

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.

Attachment: signature.asc
Description: PGP signature


reply via email to

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