Sorry, hit the wrong button and the email went out incomplete, if yo read the other mail you can skip to (--).
Am Mittwoch, den 11.04.2018, 13:51 +0200 schrieb Gert Wollny: > Am Mittwoch, den 11.04.2018, 07:08 +0000 schrieb Lumin: > > Hi folks, > > > > I'm sorry for repeating this topic in -devel without reading all > > the > > followups in this thread [1] which seems to be dying. Is there > > any conclusion in the thread[1] ? > As the initator of this thread I'd like to chime in. My main point of this thread was about what could be done to make the NEW process a bit more transparent. One conclusion was that for new packages that close ITPs one could add some code to dak that would append the reasons for rejections to the ITP. Looking at the code I realized that for someone not familiar with the code base it is not simple to add this, and the DD who pointed me at this and is amongst the authors of dak couldn't give me helpful pointers how this could be implemented, so for now this is stalled, but it is still on my mind. The second part, asking others to give additional reviews to the package before the first upload, and document these in a bug report and the changelog one can simply do. (--) In any case my issue was not so much with a first upload taking a long time, but that a re-upload of an already reviewed package waited in the pipeline for a long time, even though it already got a thorough review by ftp-master. In fact, I completely understand if a complex package takes some more time in NEW when uploaded for the first time. I might add that in case of the package I was talking about there vtk7, I got another reject because I used the same version for the re- upload, and after that long time it was assumed that the comments that were already stored in the ftp-masters data base refereed to this upload (*). However, after pointing this out to Chris Lamb and re- uploading the package another time he checked and accepted it in less then 24 hours (big thanks again). At this point I might add that there should probably be some policy how to version re-uploads after a non-automatic ftp-reject. The discussion whether one should change or keep the version number is also not conclusive, but after what happened to vtk7 I personally will now always increment the version after an ftp-reject, but without adding a new changelog entry. *) I wonder if and how this data base is actually accessible for non- ftp members? Best, Gert