[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

A proposal for improving transparency of the FTP NEW process

Dear all, 

as the one who is the uploader of the package that is currently longest
in the NEW pipeline (vtk7), I'd like to make a proposal how
transparency and also the interaction from non ftp-master members to
review packages could be improved.

Short version: Use the salsa per-package issue tracker for problems
that come up with the review in NEW.

Long version: 

First a short piece of history about this package: The version
currently in the pipeline is a second upload, after ftp master
(rightfully) complained about a bunch of files with questionable
copyright (not even upstream could clarify the situation), and some
other issues that we all fixed, I re-uploaded the package and now it
sits there for six month. Granted, the package is quite big, and being
a reviewer as ftp-master is a tedious job, but I would have hoped that
a second upload dedicated at fixing the indicated problems would result
in a shortened review time, because the review could focus on these
issues only. 

For this reason, to make the review process a bit more transparent, and
also to make it easier for others who want to help reviewing packages
in a visible way, I'd like to propose the following: With the new
gitlab environment on salsa every package hosted there has an issue
tracker that can be enabled. Given that Debian user-visible bugs are
tracked in the usual Debian bug tracker, I'd suggest to use these issue
trackers (also) for problems that relate to packages in the NEW
pipeline. Some teams already use the issue tracker for tracking work on
packages that is of not much interest to Debian users. Adding the
issues related to packages are still under review by ftp-master before
they can enter the archive seems like a logical step to me.

Now, if the reviewers of a package finds a problem, they could open an
issue in the issue tracker for this package as they go. This has the
nice effect for the maintainers that they could see early in the
process if something needs fixing, and they could already work on it
before ftp-master send the summary reject message. In this reject
message ftp-master cold simply list the issues like given in the
tracker. Since teams and maintainers might use the issue tracker for
other work as well, some unique label, like "new-pipeline" could be
helpful here.   

Since ftp-master also sometimes sends messages like "I let it pass for
now, but please fix it with the next upload", using the package issue
tracker would also be a way to keep track of these minor issues.
Specifically, because some package have to go through NEW only once in
there lifetime, issues like these might get overlooked if they are not
tracked properly.

Because closing an issue with a commit message nicely adds a link to
the corresponding commit, the reviewer of a re-upload has an easy way
to check how the issues with the package were closed without navigating
through the file hierarchy of the package, hopefully making a second
review faster.  

In order to not interfere with the Debian bugtracker, the commit
messages used to close these issues on salsa could only use "fixes" or
"resolved" instead of "closing" to close an issue.

The nice thing about this approach is that all the infrastructure is
already in place and maintainers only need to enable the issue tracker
for their packages before they do an upload to new. 

What do you think about this? 


Reply to: