On Tue, Aug 12, 2003 at 06:29:27PM +0100, Colin Watson wrote:
> On Tue, Aug 12, 2003 at 11:10:27AM -0600, Joel Baker wrote:
> > On Tue, Aug 12, 2003 at 11:23:01AM +0100, Colin Watson wrote:
> > > In my experience, this is almost always better handled by gradual
> > > rewriting than by a total ground-up effort. You get validation at
> > > each stage; it's easier for other people to review the changes and
> > > confirm that functionality and correctness haven't been lost; and
> > > you can introduce improvements to users more quickly because they
> > > don't have to wait until a huge rewrite-from-scratch is stable
> > > enough to deploy. There are exceptions, but I believe they're very
> > > rare.
> >
> > There's one problem that dpkg has which most other things don't, which
> > would make 'gradual change' into an extremely painful thing, if even
> > practical: the Debian release cycle.
> >
> > For good or bad, Debian releases are taking *at least* 2 years, these
> > days. And dpkg, being part of the core setup, can only make
> > significant changes in 2x that amount (one release to introduce new
> > stuff and deprecate old, one release to get rid of the old).
>
> That's only a concern if there's some old to get rid of, and even then
> only if it's not possible to keep the existing interface seen by
> packages. I think this applies to mercifully few dpkg changes. In
> particular, it doesn't apply to new features, provided that there's some
> way you can test them reasonably before packages in the archive are in a
> position to use them. The Breaks: field (less violent version of
> Conflicts:, discussed many years ago; see
> http://lists.debian.org/debian-devel-9710/msg00643.html) is a good
> example of this.
>
> Given the number of packages in the archive and the human effort
> involved in changing all of them, we should be avoiding major interface
> changes in dpkg wherever possible anyway.
Hmmm. Think-o (regarding 'old' going away). See below.
> > 4 years per gradual change is not exactly a stunningly good time to
> > try to rewrite things piecemeal.
>
> There's a big difference between "redesign the interface" and "rewrite
> internally".
There is, indeed. I don't generally assume "rewrite from scratch" also
means "toss out the interface" (unless we're talking about a library with a
major-version soname change - even then, it's usually very similar to the
last one). I do assume that it may well mean new features or capabilities
for that interface - which cannot be used until the version *in stable*
understands them, so far as I understand.
Actually doing proper incremental changes means you verify at each step of
the way that the changes are working - not just with automated tests (which
are a crucial starting point), but by putting it into production as well,
and seeing what falls out. Ideally, 'nothing', but then in an ideal world,
one could instantly upgrade every copy of dpkg in existance, too, so.
The key point being that since it takes 1 release to get stuff into stable
at all (so that packages can use it), it's 2 years before you'll even have
anyone *trying* to use the code - and, of course, if a truly serious flaw
is found, the fix either has to go into a point release, or be delayed
another full cycle (granted, such serious flaws are rare with the current
arrangement of dpkg; I would say 'nonexistant to date', except that I
haven't dug through the archives to make sure it never happened quietly).
This is not conducive to incremental changes in a meaningful timeframe;
even if the internal changes occur incrementally, with tests to verify
them (which is a whole lot better than many situations), the difference
between any two actual releases (as in, stable -> new-stable) is going to
be massive.
If you *ARE* doing unit tests, then it doesn't matter whether the rewrite
is 2 lines of code, or 200,000 - if your unit tests still pass, then it's
fine. Or your unit tests are buggy. It's just saner to do the changes a
little bit at a time, so that you have some clue what changes actually
broke the unit tests - it won't make things any more stable.
--
Joel Baker <fenton@debian.org> ,''`.
Debian GNU NetBSD/i386 porter : :' :
`. `'
`-
Attachment:
pgpb3AlBHfuWV.pgp
Description: PGP signature