On Friday, April 29, 2022 12:08:21 PM EDT Andreas Tille wrote: > Hi Scott, > > thanks a lot for becoming involved into this discussion. > > Am Fri, Apr 29, 2022 at 11:26:33AM -0400 schrieb Scott Kitterman: > > 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. > > To give some actual examples that IMHO are candidates for accept + bug > report: > > 1. In case versioneer.py (Creative Commons "Public Domain Dedication" > license (CC0-1.0) is missing in d/copyright like in propka[1] > > 2. Packages which are DFSG free but might miss some single copyright > statement. > My favourite example would be r-bioc-basilisk[2]. In this specific > example I even disagree with ftpmaster[3] but I see no real chance > as a maintainer to discuss my point and can only re-re-re-upload > what I consider correct. So I gave up and this package is not yet > inside Debian. This could be discussed more sensibly in a bug > report IMHO. > > I think Paul was not talking about non-distributable software but rather > code that is considered DFSG free but missing proper paragraphs inside > d/copyright which can be easily fixed in BTS.
The in that case, it's just a variant of accept plus file a bug. I don't think it's productive to get into a discussion on the distinction between "buggy" and "too buggy to go in the archive". It's very dependent on the specifics of the situation. Also, accept with severe bugs and remove later if not fixed requires someone to track these issues and follow-up on getting them removed. That seems like more work that isn't easily automated (we don't do automatic removals from Unstable now - they are at most semi-automatic where an FTP Team member still needs to review and do the actual removal). To summarize: The reject/prod messages are already not considered private. Any additional addressing of them to whatever location in the BTS is a matter of have the BTS be ready for it and adding it to process-new to send it. If the answer is that ITP bugs are now required, then policy should be updated first. It would be useful to have a mechanism within DAK process-new to file a bug with the prod note of the appropriate severity. I think if this existed you would be inclined to see more accept with bug resolutions. I think accepting something to buggy to remain in unstable and removing it later if not fixed is not something that should be pursued. Still not speaking for the FTP Team. Scott K
signature.asc
Description: This is a digitally signed message part.
