Re: Building glibc 2.0.7 using hamm
> > The problem is that the "more functional" means the creation of new bugs
> > in addition to the fixing of some older ones.
>
> I've heard this theory from you before, and I don't subscribe to the
> automatic nature of this idea.
>
> Adding a well defined feature with clearly understood code impacts creates
> a narrow window for incorperating new bugs, but it also makes the
> testing/vetting process for that code much clearer than with the complete
> collection of code.
Except that presumably this was also done for the previous release and
yet there are always bugs. It's just a fact of software development.
By upgrading to include a new feature, you run the risk of allowing in
a fairly major bug with limited time to detect and deal with it. Since
we're still early on in the freeze, I've been pretty lax with this,
but I want to tighten it up considerably.
There is also the issue of testing. As you well know, your testing group
has greatly limited resources. Once full system integration tests begin,
I plan to only allow severe bug-fixes in. A very small bug fix might be
just that, but it may also introduce a very big bug that would not get
cought. It's a matter of weighing the known against the unknown. While
the known is always more urgent, it's not always more important.
> > If the changes from .10
> > to .26 were bug-fixes only, there would be no problem.
>
> Why is there some magical difference between new code inserted to fix a
> known bug, and new code inserted to provide additional functionality
> (like, for instance, an option to turn on, or off, some portion of
> existing functionality)
>
> Both activities are about equally likely create a different bug, and these
> can usually be identified before releasing the package, and backed out.
A bug fix is usually a very small change to the code. They are seldom
more than a couple lines of code. Adding a new feature can be a huge
amount of code. Of course, the one you describe (a command-line flag)
is very small, but if that were the majority of features we'd have a lot
of pretty useless software out there.
If the chance/severity of an introduced bug is proportional to the number
of lines of source code added/changed (and I believe it is), then the feature
has a much greater chance simply because it's much bigger.
If the chance of finding any given bug is constant (which seems reasonable),
then a certain percentage of bugs will always slip through. Thus, the more
bugs intrudoduced, the more bugs get released regardless of how effective
you are at finding those bugs.
> > release are steps along the development cycle, there is a large potential
> > for problems.
> >
> All releases are "steps along the development cycle". They all have
> potential for problems.
Not always true. The kernel for example, has separate development and
stable streams. When bugs are found, they are applied to both streams.
New features, however, and added to only one.
Brian
( bcwhite@verisim.com )
-------------------------------------------------------------------------------
Tired of spam? See what you can do to fight it at: http://www.cauce.org/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: