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,
Daniel
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
http://mixxx.org
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
http://mixxx.org
Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
