On Fri, 2022-04-29 at 11:26 -0400, Scott Kitterman wrote: > 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. The proposal essentially turns most Reject mails into Prod mails and turns all Prod mails to bugs. The only Reject mails that will be sent are if the bugs aren't being solved after a certain amount of time, then the packages will be removed from NEW and get a REJECT. > 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. That makes it seem more reasonable to make everything public, also I note the REJECT mails are available to all Debian members. ssh://mirror.ftp-master.debian.org/srv/ftp-master.debian.org/queue/reject/ I have been reading these files and note that many of them are automated, probably the most common one is people mistakenly doing source-only uploads to NEW. I have another idea to add a pre-reject API to dakweb for use by dupload/dput/dput-ng but haven't a proposal yet. > 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. That seems reasonable. > 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. The proposal was created because I think filing WNPP bugs for every NEW upload is very much suboptimal, so I came up with the proposal as an alternative to that, so I'd avoid filing additional WNPP bugs for NEW above the existing ITP/etc bugs. > 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. One advantage of this proposal is that it allows filing bugs against any package already in NEW, so you could do that even if you notice a minor issue while processing a package, then have to move on to something else, then come back to the package the next day. > 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. That seems like a useful feature, but I think I would separate this into two steps, first file the bug, maybe from dak and then accept. > 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. That is definitely *not* what was proposed, and I think it is a bad idea to accept packages that are not suitable for the archive. The proposal is simply to change the NEW packages feedback mechanism and change the procedure for packages that don't yet meet Debian standards. > If a package is not suitable for the archive then it should be rejected with > appropriate feedback and re-uploaded. The proposal is to instead of rejecting the package, keep it in NEW, file a serious bug against the package in NEW, wait for it to be fixed and then reprocess the package. > Note: Although I am a member of the FTP Team, I am only speaking for myself > here, not the team as a whole. Thanks for your response. -- bye, pabs https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part