On 2026-02-06 at 07:07, Jeffrey Walton wrote: > On Fri, Feb 6, 2026 at 3:27 AM Faith Nyakerario > <[email protected]> wrote: > >> Hey all, >> >> My name is Faith Uniter, a new Debian contributor. I recently >> started learning how to report bugs using my terminal. I’m running >> into some uncertainty that I’d appreciate guidance on. >> >> In my case, Helping newbie developers Helping newbie developers >> >> at https://lists.debian.org/debian-mentors/ but I’m not entirely >> sure how to determine whether what I’m observing should be reported >> against a specific package or treated as a more general issue. > > debian-mentors is a useless list. No mentoring goes on there. The > traffic seems to be bug reports. It should be called the debian-bts > list or similar.
That's not entirely accurate or fair, although I agree that the name is somewhat misleading. What that list is used for is for people who maintain Debian packages, but are not Debian Developers (and therefore do not have the access rights to upload those packages into the archive), to seek sponsorship by Debian Developers to get those packages uploaded. The process for seeking sponsorship involves filing Request For Sponsorship (RFS) bugs, which then get routed to that mailing list. Once a potential sponsor picks up a given request, there will often be some back-and-forth discussions as the sponsor reviews the proposed package and makes sure that it seems to meet the qualifications to be included in the Debian repositories. Those back-and-forth exchanges are where the mentorship on the list takes place; the specific examples of the packages involved are used as the training material, and help show what areas the person involved needs help in, by virtue of in what areas the packaging work needs improvement. There are *many, many, many* bug reports which do not go to debian-mentors, and would not be appropriate there - so "debian-bts" would not be an appropriate name for the list. I do grant that the process which takes place there does not, on the surface, appear to much resemble what persons unfamiliar with that process might expect from the word "mentor". It does, however, serve some of the same purposes in the end - just by a somewhat different channel. If the list were being created nowadays, with the benefit of being able to draw on experience of what takes place on it, I suspect that the name that would have been chosen for it would not have been included the word "mentor". But at this point the name is set, and uprooting things to try to change to a different name - even if one that people could agree on were to be found - would almost certainly be more trouble than the result would be worth. > (I made the mistake of trying to grow my Debian skills using > debian-mentors years ago. About all that happened was, my Inbox > filled with bug report spam). I handle the inflow of messages from debian-mentors by having set up a folder for them to go into, and a filter (based on the List-Id header) to direct incoming messages from that list into that folder. That's been my standard practice for all of the numerous mailing lists I've subscribed to over the years. The workflow many people seem to adopt of leaving everything in the Inbox (at least until they've looked at it) frankly seems a bit strange to me, although it certainly does seem to work for at least some of them. >> Could someone please advise on: >> >> 1. >> >> How to reliably identify whether an issue should be reported >> against a specific package versus a general bug? Issues should almost always be reported against specific packages. Bugs against the 'general' package are almost never appropriate. They go to the debian-devel mailing list, and tend to see one of three things happen: * The bug report gets no response, and sits untouched indefinitely. (This is not very common, in my experience.) * The bug report gets reassigned to a more specific package, either immediately, or after a bit of discussion. * The bug report gets closed as being either a user support request (which typically gets a message directing the user to come here instead) or not including enough information to be even remotely actionable. The number of potential issues which could be appropriate to file under the 'general' package in their own right, and not because you can't figure out where to file them, is *vanishingly* small. >> 2. >> >> How a contributor can get a reported bug assigned to themselves >> for follow-up and fixing? I could be mistaken, but I'm pretty sure that's not how the Debian bug tracker works. In the Debian bug tracking system, bugs are assigned not to people but to packages. Anyone can subscribe to any bug report (which mostly means: they will receive copies of any mail sent through the bug report), and attempt to act on it as they see fit, including potentially sending fix-the-bug patches as attachments to the bug report. The listed maintainers for a package are automatically subscribed to every bug report for that package. As far as I'm aware, that's the closest thing to assigning a bug to a contributor which the Debian bug tracker supports - and the only benefit it seems to bring is being able to be automatically notified of any new bug reports filed against the package; it doesn't seem to have any real effect as far as already-filed bug reports goes. >> Any pointers to documentation, best practices, or examples would be >> very helpful. It depends on what type of thing you're looking to learn how to do. If you think you may be interested in becoming the maintainer for one or more Debian packages (whether existing ones that need the help, or new ones that you create yourself), you might find some benefit from starting with: https://wiki.debian.org/how-can-i-help/ That page is related to a program available in the 'how-can-i-help' package. The aim of the program is to help people find packages where a new maintainer, or extra hands to assist the current maintainer, would be useful. You might also find benefit from reading the Debian New Maintainers' Guide: https://www.debian.org/doc/manuals/maint-guide/ That's a much more technical document, about the specific functional details of Debian packaging mechanics, but it can be very valuable to someone who's trying to learn how to create and maintain a Debian package. There's also the Debian Packaging Tutorial, which is available in several languages from: https://www.debian.org/doc/devel-manuals#packaging-tutorial and is also available in the 'packaging-tutorial' package. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
