4 ms·

> Especially, it seems to be impossible to add custom searchable fields (like "platforms", "priority" or "modules") which are very very useful to do queries. Al

> Especially, it seems to be impossible to add custom searchable fields (like "platforms", "priority" or "modules") which are very very useful to do queries. Also, there is no way to do custom queries and store them ("I want all the bugs for Windows, which are related to the interface modules"). Isn't this use-case covered by Gitlab's issue labels?

jbk 11y ago
I don't think so. Labels are too limited. We want for every bug, that a few custom fields are always defined, to do a partition of the bugs, and to be able to query on those. Moreover, to change the priority or the platform, it's quite complex to do and will break often. Many bugs won't have it filled, for example. Labels do not guarantee that consistency. As you can see, it's already what people want in the github open letter.
- rplnt 11y ago
  Just curious, what options would be there for a platform filed? What I'm aiming at are issues that are present on all mobile platforms, all desktop platforms, all x86, ... etc. Either you'd have another dozen of cross-categories or you'd have to use something like check-boxes, which are essentially labels. Maybe having some set of mandatory labels? I.e. at least one label from platform list, at least one label from priority list, etc...
technomancy 11y ago
If you have to create a label for every platform you support and every existing priority and module, the labels list will become really cluttered, making it hard to find things.
- masklinn 11y ago
  It becomes very long, but it doesn't seem overly cluttered, and it avoids the risk of overly restrictive either/or classification. Rust makes extensive uses of labels on github, they're up to 120 at this point[0] and it seems to work reasonably well even with old issues with a fair number of labels[1] [0] https://github.com/rust-lang/rust/labels https://github.com/rust-lang/rust/labels [1] https://github.com/rust-lang/rust/issues/5016 https://github.com/rust-lang/rust/issues/5016
  - unethical_ban 11y ago
    FWIW, at my office for the small projects we have tracked, we use a similar method. type-label Types: b - bug f - feature p - priority t - team So we might have issues tagged "p-med b-confirmed t-group1" Once there is a method to the madness, it's not bad, and it's more flexible on Gitlab's part I'm sure, to have people tag instead of supporting custom drop-down attributes.
e12e 11y ago
I don't know gitlab very well, but I maintained a few trac instances - the thing about trac is that it is (was) an issue-tracker framework rather than a one-size-fits-all out-of-the-box solution. Have a look at: http://trac.edgewall.org/wiki/TracReports http://trac.edgewall.org/wiki/TracReports http://trac.edgewall.org/wiki/TracQuery http://trac.edgewall.org/wiki/TracQuery http://trac.edgewall.org/ticket/1735 http://trac.edgewall.org/ticket/1735 Add in: http://trac.edgewall.org/wiki/TracTicketsCustomFields http://trac.edgewall.org/wiki/TracTicketsCustomFields And there's a lot of things available before adding custom plugins. I'd be interested to hear what limits vlc hit in trac (and why they'd rather move than improve trac. Nothing wrong with that - but I confess I have a soft spot for trac and the team's ethos of "try it as a plugin before making it a core feature"). Also curious if anyone know what, if anything happened with the Apache Bloodhound fork/distribution? http://bloodhound.apache.org/ http://bloodhound.apache.org/ I always hoped it held the promise of being a simple to install, opinionated trac for multiple (lean?) projects. But as far as I can tell it was pretty much abandoned. While part of it might be rails-angst and fear of precious stones - I always felt gitlab was a bit of a heavy hammer in terms of install/dependencies/cloc for "just" project management. In practice the bundled distribution alleviates that - but I still feel taking the "best of trac" and writing a new system a little more opinionated (and probably with a clearer data model) would be worthwhile. Just another project on the todo-heap :)

jbk 11y ago

I don't think so. Labels are too limited. We want for every bug, that a few custom fields are always defined, to do a partition of the bugs, and to be able to query on those. Moreover, to change the priority or the platform, it's quite complex to do and will break often. Many bugs won't have it filled, for example. Labels do not guarantee that consistency. As you can see, it's already what people want in the github open letter.

rplnt 11y ago
Just curious, what options would be there for a platform filed? What I'm aiming at are issues that are present on all mobile platforms, all desktop platforms, all x86, ... etc. Either you'd have another dozen of cross-categories or you'd have to use something like check-boxes, which are essentially labels. Maybe having some set of mandatory labels? I.e. at least one label from platform list, at least one label from priority list, etc...

technomancy 11y ago

If you have to create a label for every platform you support and every existing priority and module, the labels list will become really cluttered, making it hard to find things.

masklinn 11y ago
It becomes very long, but it doesn't seem overly cluttered, and it avoids the risk of overly restrictive either/or classification. Rust makes extensive uses of labels on github, they're up to 120 at this point[0] and it seems to work reasonably well even with old issues with a fair number of labels[1] [0] https://github.com/rust-lang/rust/labels https://github.com/rust-lang/rust/labels [1] https://github.com/rust-lang/rust/issues/5016 https://github.com/rust-lang/rust/issues/5016
- unethical_ban 11y ago
  FWIW, at my office for the small projects we have tracked, we use a similar method. type-label Types: b - bug f - feature p - priority t - team So we might have issues tagged "p-med b-confirmed t-group1" Once there is a method to the madness, it's not bad, and it's more flexible on Gitlab's part I'm sure, to have people tag instead of supporting custom drop-down attributes.

e12e 11y ago

I don't know gitlab very well, but I maintained a few trac instances - the thing about trac is that it is (was) an issue-tracker framework rather than a one-size-fits-all out-of-the-box solution. Have a look at: http://trac.edgewall.org/wiki/TracReports http://trac.edgewall.org/wiki/TracReports http://trac.edgewall.org/wiki/TracQuery http://trac.edgewall.org/wiki/TracQuery http://trac.edgewall.org/ticket/1735 http://trac.edgewall.org/ticket/1735 Add in: http://trac.edgewall.org/wiki/TracTicketsCustomFields http://trac.edgewall.org/wiki/TracTicketsCustomFields And there's a lot of things available before adding custom plugins. I'd be interested to hear what limits vlc hit in trac (and why they'd rather move than improve trac. Nothing wrong with that - but I confess I have a soft spot for trac and the team's ethos of "try it as a plugin before making it a core feature"). Also curious if anyone know what, if anything happened with the Apache Bloodhound fork/distribution? http://bloodhound.apache.org/ http://bloodhound.apache.org/ I always hoped it held the promise of being a simple to install, opinionated trac for multiple (lean?) projects. But as far as I can tell it was pretty much abandoned. While part of it might be rails-angst and fear of precious stones - I always felt gitlab was a bit of a heavy hammer in terms of install/dependencies/cloc for "just" project management. In practice the bundled distribution alleviates that - but I still feel taking the "best of trac" and writing a new system a little more opinionated (and probably with a clearer data model) would be worthwhile. Just another project on the todo-heap :)