Re: Updated proposal for improving the FTP NEW process
On 14967 March 1977, Gert Wollny wrote:
I so like proposals from people who have never ever done any of the work
they propose something one. BUt hey...
> (1) Given that all new source package come with an ITP bug, when a
> package must be rejected, the FTP team could CC this bug in the
> rejection message. This would have the advantage that for everyone
> interested in the package the information why the package was rejected
> can easily be found. In addition, For large packages, where a review
> takes more than one day, the reviewer could send messages to the ITP
> about problems the moment they are found, so maintainers could start to
> work on correcting the errors earlier.
If someone comes up with a patch to process-new which does this in a
halfway reliable way, it doesn't need a long time wasting thread on
devel to get it.
> (2) To improve the initial quality of uploads to NEW I also propose the
> introduction a (voluntary) review step: Someone who is interested in
> getting additional reviews to a package before uploading it to NEW
> could file a "Request for review" (RFR) bug against wnpp. Then those
> who are willing to review packages can step in and also have a common
> place to comment on problems of the package that need fixing. When
> someone satisfied with the package they add a comment to the bug
> "Reviewed-By: name <email>", and when doing the actual upload, the
> maintainer replicates these R-B messages in the changelog closing the
> RFR bug. For large packages one might also add a comment "subir/module
> X Reviewed-By: ..." to indicate only a partial review.
> This R-B- information could also be added to that persons QA page under
> a new section "Reviewed Uploads".
> In a way this replicates what sponsors do for uploads of non-DDs, but
> especially for large packages a second pair of eyes is always helpful.
And that is thankfully something everyone can just do (ask your peers
for review). And is something that got proposed tons of times. Never see
anything come from it.
> Implementing the first point is essentially up the the FTP team.
No its not, its up to the ones that want it to patch dak process-new.
That is, parsing the bug-close list (if any), finding out if thats
really an ITP, and if so, CC it on rejection/prod.
Note that this has to be automatic, if it requires us to enter anything,
it is doomed to fail.
--
bye, Joerg
Reply to: