On Wednesday, April 27, 2022 8:54:05 PM EDT Paul Wise wrote: > Hi all, > > During the discussions about NEW on debian-devel in recent times, I had > the idea that instead of the current mechanism of sending REJECT mails, > Debian could switch to using the BTS for most feedback on NEW packages. > > This means that most discussion about NEW packages would become public, > but of course the ftpmasters could opt to send private mail instead if > in some cases if there were sensitive issues to be discussed. > > The ftpmasters could simply file severity serious bug reports against > NEW packages that have issues blocking their entry into Debian. When > there are minor issues noticed at the same time, then file bugs of a > lower severity. Only when a NEW package has not had its serious bugs > fixed in a long time would an eventual removal and REJECT mail happen, > perhaps after a few months of zero action on the bug reports. > > The changes that are needed to make this happen include: > > The community needs to decide that this change is a good idea and be > willing to recieve most feedback on their work in public. > > The BTS and ftpmaster teams need to agree with this change. > One BTS admin said this is feasible in principle and one of the > ftpmasters seemed to like the idea when I mentioned it on IRC. > > Where the bug mail should go to needs to be decided on. Personally I'm > thinking the person who did the upload plus the Maintainer field. > > The people doing processing of NEW packages need to be willing to file > bug reports against them where necessary. > > dak needs to export debian/changelog version lists for NEW packages. > > debbugs needs to import packages/versions from the new.822 file: > > https://ftp-master.debian.org/new.822 > > dak needs to link to the BTS from new.822 and the NEW packages info. > > https://ftp-master.debian.org/new.html > > The technical work needed here is minimal, so if there are no other > volunteers to do that work, then I would be willing to do it. I have > experience with Perl/Python but only a small amount of experience with > working on the debbugs and dak codebases. > > Thoughts welcome, especially from those who don't like this idea. This proposal has a number of parts and I'm not entirely confident I understand what it being proposed. A few thoughts/clarifications. 1. Making reject/prod emails more public: There are actually two different types of messages we can send while reviewing packages in DAK: a. Reject: As indicated by the name, this is an email that accompanies the package being rejected from the New queue. b. Prod: These leave the package in New and are used to ask the maintainer a question. My recollection is that these go to the maintainer and changed by. In many cases the maintainer is a team, so these are already not considered private. Whatever is done in this area should definitely be integrated into DAK as part of process-new. I don't think it would be helpful to try to add steps to the work the FTP Team has to do. New is slow enough that we should definitely not make is slower. Also, if any of this will depend on the existence of a WNPP bug, then policy should be changed to require them. They are currently not required and not everyone files them. If something is going to be required to get a package accepted, it should be in policy. On a related note: It is not unusual for me to notice packaging issues which are not serious enough to reject the package, but should be documented. This is particularly true when an existing package goes through New due to a new binary package. It would be useful to have the option to accept with bug report so that we don't need to go through the steps of filing a bug by hand. When I do this I also send a prod to the uploader/maintainer and it's effectively doing work twice. Making New processing more efficient will help make it faster. 2. Not rejecting packages with serious defects: I'm not sure I understand what it proposed: > The ftpmasters could simply file severity serious bug reports against > NEW packages that have issues blocking their entry into Debian. When > there are minor issues noticed at the same time, then file bugs of a > lower severity. Only when a NEW package has not had its serious bugs > fixed in a long time would an eventual removal and REJECT mail happen, > perhaps after a few months of zero action on the bug reports. I think this proposes to accept all packages regardless of how defective they are and then remove them later if the bugs aren't fixed. If that's what is proposed, my thought is absolutely not. If a package is not suitable for the archive then it should be rejected with appropriate feedback and re-uploaded. Note: Although I am a member of the FTP Team, I am only speaking for myself here, not the team as a whole. Scott K
Attachment:
signature.asc
Description: This is a digitally signed message part.