Re: Urging for solution to the slow NEW queue process (completeed)
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
Reply to: