On Fri, 07 Mar 2025 at 13:27:54 +0530, Pirate Praveen wrote: > On 7/3/25 12:29 AM, Otto Kekäläinen wrote: > > > Around 12 years ago, I proposed a peer-review system to increase the > > > quality of > > > the packages in the NEW queue. https://wiki.debian.org/CopyrightReview > > For packages that I sponsor, I already do reviews of the > > debian/copyright and all other files. These are recorded as Merge > > Requests in Salsa. Perhaps the easiest way to achieve the workflow you > > envision would be to have a field in the upload metadata that links to > > the Merge Request on Salsa, so FTP masters can see who reviewed the > > contents and if their feedback was properly addressed in addition to > > reviewing the uploaded artifacts from scratch? > > > May be this can go to changelog? As adding new filed may need tools and > people to adjust and can take a long time.
If the public NEW-queue viewer at https://ftp-master.debian.org/new.html is an accurate reflection of the files that the ftp team would look at first in their internal processes, then the top changelog entry (but only the top changelog entry, and not later ones), debian/README.source, or the copyright file itself would be the places to put evidence supporting the copyright file being correct. A change history of problems that were reported and fixed doesn't seem like something that would speed up the ftp team's work: if they feel that they have to review a change history *in addition* to reviewing the uploaded artifacts, I don't see how that would take a shorter time than only reviewing the uploaded artifacts. The only way this could help is if the ftp team were willing to trust the information from peer review and do a less in-depth review of packages that have had a positive peer review, but I have not seen any indication from the ftp team that they would be prepared to do that. So I think it could be better to frame this in terms of finding a good place to put supporting evidence ("I know the licensing situation in contrib/foo/ looks strange at first glance, but in fact it's OK because..."), rather than somewhere to put a change history of previous negative feedback being addressed. The ftp team don't need to know about the existence of previous, wrong packages, they are only approving or rejecting the hopefully-correct final package that has been submitted for their review. smcv
