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:
https://github.com/mixxxdj
https://gitlab.com/inkscape/
https://launchpad.net/mixxx
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:
https://gitlab.com/gitlab-org/gitlab-ce/issues/17186
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.
https://docs.gitlab.com/ce/user/project/import/github.html
This sounds the same as compressing and mp3 with aac :-P
Kind regards,
Daniel
------------------------------------------------------------------------------
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
