Maybe I've missed the conversation. What about GitHub issues doesn't fit
requirements?
On Sat, Nov 18, 2017, 6:30 AM Daniel Schürmann <dasch...@mixxx.org> wrote:
> 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
> 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
------------------------------------------------------------------------------
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
