[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian Rust usertags



On Sat, Sep 27, 2025, at 12:58 AM, Jonas Smedegaard wrote:
> Quoting Matthias Geiger (2025-09-26 17:50:55)
>> On Fri, 26 Sep 2025 17:35, Jonas Smedegaard <jonas@jones.dk> wrote:
>> >Quoting Jeremy Bícha (2025-09-26 15:23:57)
>> >> I believe that we have made some progress on your bug reports this
>> >> week,
>> >
>> >I think so too - thanks to everyone involved!
>> >
>> >> but I don't see an easy way for me to track your open requests.
>> >
>> >That one is easy:
>> >https://bugs.debian.org/pkg-rust-maintainers@alioth-lists.debian.net;include=originator:jones.dk
>> >
>> >> Could you try using usertags?
>> >
>> >Meybe, if we can come up with some usertags sensible to spend time on
>> >maintaining.
>> >
>> >> Maybe we could have a tag for update and another for uninstallable
>> >> since those seem to be commonly filed. I suggest using the email
>> >> address debian-rust@lists.debian.org for these usertags.
>> >
>> >What benefit do you see in tracking those types of bugreports?
>> IMO the greatest benefit is that it allows us both to filter only for 
>> bugs regarding crate transitions/updates. This helps immensely with 
>> triaging.
>> >I mean, I already find it tiresome tto file the many bugreports, and
>> >wonder if perhaps efforts are spent looking for ways to reduce the
>> >amount of suspiciously similar bugs. I am not rejecting your suggestion,
>> >and perhaps we are totally aligned here and I just don't see it. So
>> >please do elaborate... :-)
>> Since every (almmost) every transition requires alignment and 
>> coordination this would help prioritizing, too.
>
> Sorry for being dense - could you spell out to me which usertags would
> help how (not just that usertags in general helps)?

they would provide a submitter-independent way of categorizing and later
querying common bug types. I do think it would require defining a set of
tags and their meaning first though.

for example, we could have one for minor version upgrades (that *should*
be compatible), a second set for semver-breaking ones (akin to transitions),
and a third one for autopkgtest related issues? I am sure we can come up
with more, but it probably makes sense to start off with a set of tags
that match issues coming up very frequently which might be handled in a
batch fashion..


Reply to: