Re: A proposal for improving transparency of the FTP NEW process

[Ben Finney <bignose@debian.org>]

Lars Wirzenius <liw@liw.fi> writes:

> 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. […]

Your recounted experience suggests another way (compatible with the ways
you discussed) to reduce the work of reviewing a code base with complex
copyright interactions:

A large code base with complex interacting works of copyright can be
broken into smaller packages, that are each individually easier to
review and pass through NEW; either built as separate source packages,
or combined at build time.

Will that work for every large package? Maybe that's too much to hope
for. But in those cases where the maintainers are frustrated that the
NEW queue processing takes a long time to pass their new package: isn't
it worth the effort to try making it easier to review by breaking the
package into smaller more easily-reviewed chunks?

A maintainer (or a team) who tries that might find it's not so hard; and
having done that, it becomes that much easier to understand not only the
copyright status of each smaller package, but for a newcomer to
understand how to maintain it. This is a benefit not only in getting the
package reviewed through the NEW queue, but also for attracting
additional co-maintainers.

Breaking large complex tangles into smaller manageable pieces is thus,
I'd suggest, an investment in reducing the overall work of Debian
package maintenance.

> 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.

Thanks for keeping the options open.

-- 
 \                         Contentsofsignaturemaysettleduringshipping. |
  `\                                                                   |
_o__)                                                                  |
Ben Finney