Please read: "regressions"

Matt Mackall mpm at selenic.com
Tue Jan 22 12:55:29 CST 2013


I want to make sure everyone is on the same page about what a
"regression" is and how we should handle them.

On the wiki[1], a regression is defined as "a bug that breaks something
that worked in earlier releases".

These bugs are especially important, because they have the potential to
break people's _existing_ workflows and tools. Breaking people's builds
and making them wish they'd never upgraded is about the worst thing a
tool can do. We want to provide users with a monotonically more correct
set of functionality so that they needn't fear upgrading.

As such, all regression bugs should immediately be raised to urgent
priority and we should try to fix them before the next release.
Relatedly, determining whether a reported bug is actually a regression
is ALSO urgent.

It's also important to note that "performance regressions" are a
different category and care should be taken not to confuse them. Unlike
functionality regressions, which are binary, performance regressions are
on a spectrum from minor to massive. But unless it actually rises to the
level of "user can no longer do their work" (eg because it now takes 10
minutes rather than 10 seconds), it is _not_ a regression in the above
sense. It thus does not get _automatically_ ruled urgent (though we may
still decide to mark it urgent if it has significant severity and
scope).

I've noticed some things in the latter category getting marked with a
"regression" keyword. We should probably instead have a "performance"
keyword.

[1]http://mercurial.selenic.com/wiki/BugTracker

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list