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/TracQuery

http://trac.edgewall.org/ticket/1735

Add in:

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/

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 :)

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.

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...

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.

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

[1] https://github.com/rust-lang/rust/issues/5016

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.