Re: A proposal for improving transparency of the FTP NEW process
On 3/3/18 7:54 AM, Lars Wirzenius wrote:
On Fri, 2018-03-02 at 22:05 -0600, Steve Robbins wrote:
I assume that the reason my packages have been processed is due to one
of two reasons: a) I get quoted on LWN several times a year, so I'm a
celebrity and get special treatment
I expect that's it.
For the avoidance of doubt, especially for onlookers: I was, of
course, being sarcastic with that LWN command, and I think Steve is
continuing by being deadpan sarcastic in response.
I wish text/plain carried font information so I could use a font to
indicate when I'm being sarcastic (Times, Helvetica, or Courier).
But you are a celebrity. Just not the kind of celebrity that gets
free coffee at Starbucks, though. Except for when you fix their Wifi,
I mean. But if I was an ftpadmin and saw a package of yours uploaded,
you'd find me priorising this up ... and if there is not something
more interesting like a new version of bsdgames that one needs to
quality-control ... being a tech-celebrity must be good for something.
And nobody diss sarcasm, please. It is a tremendous helper,
not only to stay mentally afloat but also for brain storming to help
stimulating lateral thinking. It is mainly problematic in broadcast
communication like mailing lists when you do not know with whom
you are working with.
Or possibly you have a more generous notion of "fast". Currently there are
five or six dozen packages waiting more than 2 months. That's not fast in my
books.
By "fast" I mean "less than 24 hours". I uploaded vmdb2 (new source
package) about a month ago. The timestamp of the mail saying it's
going into the NEW queue is 16:27. The ACCEPTED mail has a timestamp
of 18:00. That was on February 10.
I had this, too. Just yesterday. Thrice. My fourth package had a problem,
which I kind of knew when it was not going through as quickly.
Admittedly, it is quite a small package, but that's kind-of my point.
Making it easy for others to do the thing you need them to do is what
you can do to make things easier for you. Asking them to do more work,
or to change how they do their thing, is less likely to go well.
The Linux kernel maintainers flat-out reject large patches that dump
big changes without prior discussion. This is because it's easier for
them to digest changes in smaller chunks, and they put the
responsibility for presenting the changes that way on the people
producing the patches.
For Debian, I think we should have the same approach. Not literally
the same approach, of course, since that would mean having the Debian
package maintainer refactor the upstream code into smaller programs,
and that would just be silly.
I disagree here. We think in units. What is released together should not
be split into multiple source packages with Debian. I am still living
through that with my mgltools packages that made everyone unhappy,
also making my communication with upstream more difficult. And the
overall workto review it all is the same.
But the same approach of making it the
uploader's responsibility to present a new package in a way that makes
it easy to review it. This includes making copyright information easy,
and working with upstream to make it clear, possibly by using SPDX
markup for copyrights and licensing. For all of Debian it meants
finding or developing tools for automating extraction of copyright
information into debian/copyright in whatever manner is needed.
We have licencecheck, and if that isn't good enough, we can improve
it.
Ha! And here I agree again. We should somehow improve our infrastructure
to allow for
* an increase automation, e.g. by something like debian/licencecheck
to help customizing the otherwise unknown licenses* replies to the
ITP with
* issues to address prior to a reload? issues on salsa?Just a nything that
renders the ftpadmins' reviewing reentrant.
* maybe ftpmasters can delegate some work to an individual they trust
for some particular checks when the source tree is on salsa? We would
effectively then have temporary volunteer ftpadmin assistants.
There may be other reasons why some packages stay in NEW for a long
time. Getting information from ftp masters about the reasons why, and
a discussion of how we can make easier for them to make NEW review
easier would, I feel, take us forward better than another than us
complaining that things are taking too long.
Yes. I am very happy not to be an ftpadmin and cannot thank our
ftpadminning peers enough for their efforts. Our current infrastructure
is not really set out to be communicative in that process.
Steffen
Reply to: