Hi Be,

It's just as unreasonable to expect new contributors to sign up for 7 different accounts (GitHub, IRC, phpBB, Freenode, mailing list, Launchpad, wiki) as it is to expect long time developers to pay attention to all of them. It would be easier if there were less things to pay attention to.

Yes sure. Sean is working on it. But It is reasonable to distinguish between user support and bug tracking like we do with forums and Launchpad. User support can help each others, contributors can jump in for unsupported use cases or bugs, that should be then tracked in a different domain.

Looking dated is important. Newcomers are telling us in no uncertain terms that they don't want to use Launchpad and by and large they aren't. What features Launchpad has are irrelevant if people don't use them.

Yes, right. But I am in doubt that this is a impossible hurdle.
Remember, the user asks for free support.

Can you elaborate on "has more bug states than just open and close"? What else is needed? GitHub and GitLab both have project-defined tags that can be used for further organization. GitLab allows projects to define priorities for custom tags.

* New
        Not looked at yet, unconfirmed
* Incomplete
        Cannot be verified, the reporter needs to give more info.
        Will be closed automatically
* Opinion
        Doesn't fit with the project, but can be discussed.
* Invalid
        Not a bug. May be a support request or spam.
* Won't Fix
        Doesn't fit with the project plans, sorry.
* Confirmed
        Verified by someone other than the reporter.
* Triaged
        Verified by the bug supervisor.
        We use it for complete analysed bug that cannot be solved for a reason.
* In Progress
        The assigned person is working on it.
* Fix Committed
        Fixed, but not available until next release.
        Available in the alpha
* Fix Released
        The fix was released.
        Available in the released version

This gives an explicit info about the bug state during it's live time.
We may use Label/Tags for it but than we loose the original tagging feature, we use for group bugs under a topic. Or we mix both state and loose a lot of clarity. If we than add additional tags for blueprints, we use a single feature for tree purposes, which is at least a regression compared to Launchpad.

Blueprints are nice but not necessary. Again, tags can be used for the same purpose.

Tags are not the same, they are somehow volatile. They need explanations to understand the purpose. In Launchpad the meaning of the field is hard coupled with a workflow.

I don't know what you mean. GitLab has a nice dashboard view for its issue tracker where you can filter by milestone and tag. You can drag-and-drop between tags in this view to keep issues organized. I think GitHub now has a similar capability too.

The GitLab dashboard is only for registerd users with access rights.
I do not have discovered it for GitHub
If you compare the Homepages, you will see the difference:
Launchpad is more user focussed and giving the best overview.

One of my biggest grievances with Launchpad is how the "Wishlist" marker is mutually exclusive with a priority designation. To me it feels like a slap in the face for a feature that's important to me to be designated with the lowest priority level. IMO there is little practical difference between a bug and the lack of a feature. Something that ought to get done is something that ought to get done. Whether it's implementing a useful feature or whether it's a bug doesn't matter for how important it is.

I can't confirm his. Launchpad has no priority field, it is am Importance field. We simply cannot give bugs priorities, because we cannot force anyone to work on critical bugs first. Every contributor has its own priority list and there is no higher authority which can change it.

I look at the Wishlist marker as an exception from Importance, since it is no malfunction, which is important to fix.

We can only express the opinion of the team how Important this bug is.
The same goes for milestones. We can define milestones as a term of:
"The milestone is reached when all the assigned bugs are done"
We can express which bug will be likely merge do which version, but we cannot stop anyone from working on other things.

I think it could be really helpful to make a GitLab repository for controller mappings. We could use its issue tracker to take requests for controller mappings so users could vote for mappings they want. That would give us data on what hardware is important to map, which could guide us on what to ask manufacturers for and/or what to spend donations on.

As we did it for manuals, we may split out mappings from the main repo.

The popularity of GitHub does give it an advantage, but I do not think it is important enough that we can't leave GitHub. Please elaborate on what you don't like about GitLab's issue tracker.

GitLab has a little more issue states.
The bug states request was rejected in favour of the dashboard:
Unfortunately the dashboard is not accessible for everyone.

FWIW, GitLab allows importing from GitHub Issues. We could do a roundabout import from Launchpad to GitHub then GitHub to GitLab.

This sounds the same as compressing and mp3 with aac :-P

Kind regards,


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