Re: A proposal for improving transparency of the FTP NEW process
Le samedi 03 mars 2018 à 21:57:42+1100, Ben Finney a écrit :
> 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.
God.
I can't imagine what kind of hell it'd actually be to split up some thing as
vtk into smaller packages without massive redesign upstream.
I'm actually pretty sure I'd not like being part of it.
Cheers,
--
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.
Reply to: