Re: [all candidates] on distribution-wide changes and scalability

[Lucas Nussbaum <lucas@debian.org>]

On 17/03/13 at 15:03 +0300, Moray Allan wrote:
> >Implementing dh(1) or source format 3, notwithstanding their
> >advantages for
> >DD's, is successful if the generated binary packages are the same
> >as before.
> >Should we really focus more effort on increasing the existing
> >convergence?
> 
> No, I don't see a strong argument for it.  If, for reasons that I
> can't yet imagine, we made a decision that it was important, I would
> rather that the transition happened fairly quickly, including NMUs
> slightly earlier than I would expect under current guidelines.

Actually, I disagree that we should not focus more effort on increasing
the existing convergence. I think that it is very important that, as a
project, we work on improving our development practices (including
standardizing on the best of them). That does not have a direct impact
on users, but on the long term, having more efficient practices makes us
more likely to satisfy our users, because we will be able to package
more stuff, do it better, etc.

Discouraging the use of some development practices is part of that.
There are good reasons for not using any of dh or cdbs, not using 3.0
(quilt), so I don't think that we should force that in policy, and make
that RC bugs.
But I think that we should discuss adding lintian warning or errors for:
- packages using 1.0 format and having files modified directly
  => should move to 3.0 (quilt)
- packages using 1.0 format and simple-patchsys, quilt, or dpatch
  => should move to 3.0 (quilt)
- packages using debhelper directly (not dh or cdbs)
  => should move to dh
[ there are good reasons in some cases for doing some of the above.
  Adding lintian override in those cases would be totally OK, and also
  a good way to identify current limitations in 3.0 (quilt) or dh. ]

I would hope that the increasing visibility brought by lintian
warnings/errors, and as well as the advertised project consensus that
such practices are discouraged, would help us get rid of such practices.
On NMUing, I'm not so sure: NMUs are not a very efficient process, so I
don't think that we should actively encourage people to NMU just for
that, unless it's particularly urgent or convenient to change that for
another reason.

Lucas