On Mon, Feb 16, 2009 at 12:17:00AM +0100, David Orban <dor...@skynet.be> was
heard to say:
> Because it was archived, I had no other possibility to reply than to fill
> it again.
You need the "unarchive" command.
> The idea of removing useless game from a package manager software is
> there to keep the number of bugs low, as in 'less useless code == less
> bugs'.
So, anyone who read the bug log for this and its predecessor would
get the idea that aptitude is buried under the weight of an enormous
minesweeper implementation, and that I am doing nothing but polishing
it all day.
Just to put some numbers on it: according to sloccount, aptitude
currently contains some 56,400 lines of code. Of those, 1,085 (a bit
under 2%) are dedicated to minesweeper. But that's not really the best
count, because what is much more important is maintenance burden: how
much work does it take to keep the minesweeper branch going?
According to diffstat, in the entire time that my current repository
tracks (that's around four years), the minesweeper codebase has seen:
22 files changed, 2249 insertions(+), 408 deletions(-)
In comparison, the main body of code has seen:
777 files changed, 156354 insertions(+), 66975 deletions(-)
So if we go by the crude metric of lines of code changed, minesweeper
has 2,657 changed lines to the 223,329 that were changed in the main
code base, or a bit more than 1%.
Arguably even this makes minesweeper look like more of a burden than
it is, for three reasons:
(1) The diffstat count includes all the translation files for the
minesweeper help, but none of the translation files for the main
program's help. It also does not include the main files of the
build system, which require a lot of maintenance (in the last
few releases I've probably spent 4-8 hours just on configure.ac
and associated files, mainly due to the amount of time it takes
to test any change there), and it doesn't include the
documentation. If I include just the build system and the
English documentation (no help files or translations), the
diffstat count increases to 284072.
(2) Most of the changes to the minesweeper code over the last four
years have occurred as part of program-wide alterations, such as
when I split the curses widget set out of the main codebase.
These alterations consist of making essentially the same change
over and over again until all the sites that need to be changed
are finished, so it becomes routine and each of the changes is
relatively easy.
(3) The minesweeper code has not had active development for quite a
while now, as in a decade or so. That means that it only gets
changed for bugfixes (which are rare, since it's not being
changed) and for things where the whole program is changing.
New development is much more time consuming than ongoing
maintenance, because it requires figuring out what the program
should do, figuring out how to design the new code, implementing
the new design, and then possibly throwing all the work out and
starting over because you missed something essential. Plus, new
development tends to introduce bugs or expose existing bugs.
(4) The minesweeper code is very, very simple and straightforward.
That means that when changes have to be made, it's easy to make
them on a line-by-line basis; I could probably rewrite the whole
thing twice a day if I wanted to (I don't). In contrast,
in something like the dependency resolver or the download threads
system, it can take hours to get a few dozen lines of code
written, because you have to be a lot more careful about finding
the right spot, making sure there are no unforseen consequences
to your change, integrating into the existing system, etc.
Minesweeper is not a maintenance burden and it adds character to the
program. One of the few perks of writing code for free is that I can
produce software which is recognizably written by a human being and not
by an automaton. I get to write the other type all day,
thankyouverymuch. If you want to finance my work on aptitude, then
maybe we can discuss my development priorities.
The only thing that might convince me to remove Minesweeper is if the
translation team said it was an undue burden on them: most of the
changes over the years have been in its translations. I doubt that's
the case, though: there have been a grand total of 349 insertions into
all the Minesweeper help files over four years, and none of those files
have changed after being inserted. It's not fair to give the numbers
for po/, because the nature of those files is that they change even
when no-one has worked on them, but the number of translations in just
*one* pofile (most of which are not Minesweeper) is larger than the
number of lines in all the help.txt files put together.
I've spent far longer trying to form a polite reply to this bug
report than I've spent working on minesweeper in the last few years
*combined*. Since you are intent on keeping it open, I will mark it
"wontfix", which is an appropriate designation for a "bug" that I will
not fix, and should keep it separate from the main body of bug reports.
Daniel
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
