It feels like it would be useful to have labels for each feature gate. This would let us tag issues with the feature-gates needed to reproduce them -- it would make it easier, I think, to find all the related issues to a stabilization. Thoughts @pnkfelix, @centril, @simulacrum?
It's definitely something I've considered/wanted in the past
it's a lot of feature gates
Presumably we could even automate the process via triagebot
that said our labeling system has way too few labels
@nikomatsakis should we do this for every feature gate or just the ones we expect are a bit larger?
I think it only makes sense if we have it for every feature gate since then it's "the way" to label bugs
(and can be associated with tracking issues, etc. ~100% of the time)
@simulacrum OK so practically speaking this means that @centril adds a new label when a new tracking issue is made?
or when does this happen? when the feature gate is added?
yeah, I'd say that we wait for triagebot -- I think I should have some time today, it seem viable that such a feature could be implemented ~today
or at least by, say, Friday
We have 367 tracking issues open, but I don't know how many of those are directly associated with a feature gate
not all of them
or even most
@simulacrum what do you mean by "wait for triagebot"?
what is needed from triagebot?
@rustbot create tracking issue for bar_bar @rustbot associate tracking issue with bar_bar
we'd need to encode the template for tracking issues into triagebot but that doesn't seem too hard (and it could be edited afterwards)
the create tracking issue would open an issue, create a label with a description that points to the issue number, and leave it at that
it should probably be considered as part of an overhaul -- it doesn't quite subsume the existing
A labels --
however it does seem like unstable and in-progress features are particularly useful to track
we'll just slowly reinvent bugzilla's whole bug dependency system :)
yeah, I think
one annoying (but useful!) thing will be when we divide a feature gate into two
sure, you'd need to relabel the associated issues, but I think that's both relatively rare and probably a good thing
@nikomatsakis In those cases we probably shouldn't relabel
it seems like we clearly should
let me elaborate:
I am imagining that we take a feature gate like
impl-trait (say) and we break off one particular part of it
it's a lot of churn and the splitting into smaller gates may be about administration rather than semantic
it seems like it'd be super useful to then be able to factor out the issues specific to that feature
@nikomatsakis sometimes :slight_smile:
I think it's highly contextual
I'm curious what feature gate splits you have in mind that are not semantic
That wouldn't surprise me
@nikomatsakis well the
impl Trait bits are semantic in a sense but they are also "small parts making a whole"
and the reason for the split is administrative
@simulacrum uhm; It is easy for me to make new labels when I make a new tracking issue
I don't really know what you mea by administrative
I'm not sure triagebot needs that feature
but I feel like when we're choosing to stabilize etc
we should be able to use these feature gates to find relevant things
and in that case it seems like we absolutely want things re-labeled
I suppose for now we could do it manually -- my thought is that at some point we'd probably want to do more with the tracking issues then just labels
@nikomatsakis I suppose yeah; but I'd want both
F-type-alias-impl-trait on an issue
to have the larger picture and the smaller part
I think historically I've wanted to, for example, have triagebot add links to relevant issues to the tracking issue header (sort of like rfcbot concerns)
@simulacrum If it isn't automated it doesn't seem super worth it
e.g. if triagebot is going to automatically add labels when a feature gate is mentioned that's one thing
I feel unless triagebot is going to take over merging RFCs then what is the point of
@rustbot create tracking issue for bar_bar ?
where do you even write that?
on either an RFC or PR (for libs features, mostly) -- and that gives you crosslinks from that PR to the tracking issue
maybe this isn't actually all that helpful, I'm not sure
@simulacrum for PRs maybe yeah; but for RFCs it would need to do a lot for me to be worth it
basically implement https://github.com/anp/rfcbot-rs/issues/198
and rfcs don't get merged that often
sure, I suppose
if you want to create labels for all the feature gates and manage all that then that seems fine by me, just feels like at least some of it could be automated
It's not a lot of overhead; I press
l on my keyboard and then type in the name of the feature gate and maybe color it a bit; done
but labeling associated issues is much more work
but it also seems like necessary work for the labels to be meaningful
@simulacrum sure; but that's a different command than
I guess we can leave that to modify labels for the time being, yes
nikomatsakis I suppose yeah; but I'd want both
F-type-alias-impl-traiton an issue
I think the A- labels still have a role here, indeed. If nothing else, once things stabilize they don't have a feature gate :)
(Note that feature gate labels would also be useful for prioritzation)
@nikomatsakis @simulacrum I'll just need to remember to do this now ^^
We'll likely want to update triage documentation on forge and mention this in the release team (wg-triage?) meeting next week, and ping dpc on the forge PR
@simulacrum can you add an agenda item?