This is a wishlist item I filed in 2005. The archived bug number is 300759. You can see the Debian report log for this bug @ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300759. After remaining silent for more than 3 years, Daniel Burrows decided to close it in August 2008 without any discussion with me (the submitter) or the members of the Debian community that were in favor of that change. Because it was archived, I had no other possibility to reply than to fill it again. So here is the message that I reveived from Daniel Burrows after 3 years: " I don't know why this was never closed, but it has never been a bug and it continues to not be a bug. There are enough real bugs that there's no reason to keep this one open. Daniel " This is my reply: " This has been filed with a severity of wishlist. So you're actually right, this is a wishlist item, as understood by Debian, rather than a bug, but we already knew this, right? 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'. As a package maintainer, you should probably focus yourself on fixing actual bugs rather than arbitrarily closing wish requests to keep the number of bugs artificially low. Doing this without any preceding discussion with the submitter, even though the community seems to be following the reasoning behind the wish is a nonsense and a lack of respect. Especially in the context of a community based distribution like Debian. David Orban. " And this is my original submission: " I am wondering why the minesweeper feature has been included in packages management software or its front-end. Correct me if I'm wrong but it seems that aptitude is meant to become an important package in future Debian distributions (i.e. called from debian-installer and maybe even considered as a replacement for dselect). Part of the basics of UNIX philosophy is to build programs that do only one thing and do it well. While it is obvious that such rules can sometimes be overruled, I can't find good arguments for this in this case. The whole system reliability depends on package such as this one and for that reason it doesn't look very serious to bring additional code, documentation and complexity for a feature which is neither necessary nor related to package management. IMHO, OS's mechanisms such as VTs should be used and minesweeper should be in its own package. For specific hardware or custom built kernels where VTs are not available, appropriate mechanisms should be used. I would like to know both the community and the author opinions about these thoughts. If one of them agrees, then the feature should probably be removed. Regards, David Orban. " As can be seen, I was asking for a discussion with the community and the maintainer and it seems that the maintainer is not really interested.
On Mon, Feb 16, 2009 at 12:17:00AM +0100, David Orban <dorban@skynet.be> was heard to say:
You need the "unarchive" command.
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
2009-02-17 03:53 Daniel Burrows: Starting from bug https://bugs.debian.org/790568 , I had originally said: > .oO I sometimes wonder if it would not be better to just remove the > minesweeper altogether. It is sort of fun/amusing and it's not a > big burden to keep it going, but as cases like these show, it's not > zero-maintainance either. To add a bit about this, in the last few years (even with development stalled for long periods of time) there were the following maintainance costs: - To address the bug #790568 For the translators, this meant to translate for years strings that were behind "#if 0", not even used (disabling the code didn't disable the strings to be gathered for translation). That is, Minesweeper had 9 short strings to translate that were really used, and 21 which are actually from what it seems to be copied from another game / project (or a previous version of the code). - The recent fix of the L/S ( https://bugs.debian.org/736934 ) -- back and forth messages and patches, applying, testing, messages in changelogs - I had to spend time in the last week to make changes to the documentation, including links to images in the section of the Minesweeper (which is one of the better documented parts of aptitude, and with many screenshots, I have to say). This part has also seen translations, and we have translations to about 8 languages now of the guide (I guess that all of them also translate the part of Minesweeper, with its screenshots). - There have been changes in translations, automake files and code in 2012-2014 All of them are often small changes, true, and as Daniel Burrows said most of them are part of wider changes in the source (automake, etc). But still, even if they are mechanical changes, that means extra mechanican changes. And that only 15 years later a translator discovers that the bulk of the gettext-translatable messages of this code didn't need translating because they are not used, after almost all of the current 40 .po files translate those lines, for me is telling that this should be disabled. Cheers.
Another little oddity caused by this feature, it is recommended by the meta-package games-minesweeper: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804793