Hi Be,

It is not fair to blame the infra structure, for the leak of time the maintainers have to manage the different informations.

Launchpad looks somehow outdated, but the important features are there.
Especially, it shows possible duplicates when filing a bug, has more bug states than just open and close, has blueprints as a second way to group bugs in addition to milestones, the blueprints. If we assumed Launchpad is well managed (I am working on that now that I have permission) it gives a well structured overview for users, what the state of the project is. GitHub is more developers focused and does not offer this clarity.

I am strictly against closing bugs, that are older then a certain deadline, because that feels like a hit in the face, for the people which may have investigated a significant time to file the bug. This happens to me in other projects and I took my consequences.

The current fragmented infrastructure, has some drawbacks, but it has  a very big advantage. You can join discussions how your time allows.

@Be: I am really happy, that you are active on all channels, thank you very much! Unfortunately, I  cannot do this because of leak of time. So I have decided not to join IRC and look to forums only when the time allows.

By the way, I have loosed long finished post more than once, because of leak of internet connection. Pressing "Submit" without a stable connection and you post is gone.  So that is really a field that could use an update.

Email works very good here. I can manage my own priority list and can reach everyone in just a second.

I fully understand Be's concerns, and I agree that GitLab looks very mature.
So we are currently in this cycle:

* We want a integrated project management structure.
* We cannot leave GitHub because of the GitHub community
* We cannot move to Gitbub issues because they do not fit our requirements and we loose the history.


Kind regards,


Am 18.11.2017 um 07:00 schrieb Be:
On 11/17/2017 02:42 PM, Sean M. Pappalardo - D.J. Pegasus wrote:
For the record, GitLab looks really interesting and exciting to me as
well. If we were a new project, we could go there in a heartbeat. But we
have to consider all of the not-fun practical matters and repercussions
of migration of a large and storied existing project.

On 11/17/2017 11:59 AM, Be wrote:
IMO our biggest issue as a project is a lack of labor.

Which is precisely why migrating at all would be problematic. We can
ill-afford the labor to do it.

I feel that the Mixxx project is in crisis and hanging by a thread. Let's stop making excuses for not taking action and start doing everything we can to make this project sustainable. We cannot afford to continue discouraging people from contributing by clinging to outdated, fragmented infrastructure.

IMO having to host our own server for project management is practically
a non-starter.

What are you referring to? In the case of improving Launchpad, our work
would be submitted upstream, to go live on Launchpad.net. We won't have
to move or change anything, just make the existing platform better.
Seems like the best return on effort invested to me.

Not one person has asked for improving Launchpad. That would take an enormous effort which I doubt would even solve the current issues. Launchpad is an outdated technology with an outdated design, let's let it die. Trying to rescue it would be an uphill battle.

On the other hand, we can join the momentum of GitLab, which has a very active company and community rapidly improving the server software. If there's something about GitLab that doesn't exactly fit what we want, we can file issues that actually have a chance of getting taking care of. We could also take care of them ourselves by sending a merge request to GitLab and not have to deal with hosting it ourselves.

A lot, if not most, of the stuff on our Launchpad bug tracker is old
noise with incomplete information.

Please do not make sweeping assertions like this without data.

In reality, 2774 (or 73.5%) of the bugs in the system are either
confirmed (adequate information,) being worked on, or already fixed. A
history of resolved bugs is very valuable in the case of regressions,
similar but new occurrences, and when users search for a common problem
they think is a bug.

Getting good data on this would require spending quite a lot of effort to clean up the mess on Launchpad. For a start we have 361 "New" bugs. We have lots of "In Progress" bugs that have had no activity in years.

I am skeptical of the importance of keeping old, resolved bugs easily accessible. The only times I remember referring to resolved bugs were to mark new reports as duplicates because we haven't had a release in 2 years so people keep reporting the same critical bugs. If needed, we could still manually copy and paste Launchpad URLs on the new issue tracker on the rare occasion that would be helpful.

This is not so much a fault of
Launchpad as it is a collective fault of the project for not using
Launchpad effectively.

Please provide suggestions on how we can better use Launchpad. Getting
the most out of existing tools is always a worthwhile endeavor.

1. Step up to assign yourselves to bugs, assign them to a milestone, and actually commit to taking care of it by that milestone. Unassign yourself from issues you don't actually end up fixing. 2. Think carefully on whether a bug is important enough and can be taken care of easily enough before assigning it to a milestone without any contributor assigned to take care of it. Assigning bugs to a milestone without assigning them to any person generates a lot of noise on the milestone. I had to spend an entire day last weekend cleaning up the 2.1 milestone so we could see what actually needs to be done for the release. 3. Be quick to mark new reports as Incomplete and let them expire if the reporter does not supply the information necessary to make the report useful.

On that note, can we get rid of this old SourceForge mailing list that
appends spam to every post?

I'm going to look at migrating it to Launchpad after the login
consolidation work.

That's not going to solve the problem of people not wanting to use email lists. It's not going to solve the problem of requiring a Launchpad account to participate fully in Mixxx development. It's not going to solve the problem of having too many communication channels. I'm pretty sure I'm the only one who keeps up with every one of them and it's way more work than it should be.

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Get Mixxx, the #1 Free MP3 DJ Mixing software Today

Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net <mailto:Mixxx-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/mixxx-devel <https://lists.sourceforge.net/lists/listinfo/mixxx-devel>

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Get Mixxx, the #1 Free MP3 DJ Mixing software Today

Mixxx-devel mailing list

Reply via email to