1 files changed, 55 insertions, 0 deletions
diff --git a/debian/bash_completion/TODO b/debian/bash_completion/TODO
new file mode 100644
index 0000000..7e213dd
--- /dev/null
+++ b/debian/bash_completion/TODO
@@ -0,0 +1,55 @@
+$Id: TODO,v 1.1 2006/03/01 16:19:26 ianmacd Exp $
+
+bash completion needs to be rewritten from the ground up.
+---------------------------------------------------------
+
+bash completion really needs to be rewritten from the ground up, using all of
+the features available in bash 3.1 and without regard for compatibility with
+the 2.x line.
+
+At that time, it should be split into multiple files for easier source
+management. Whether or not it is actually installed on the destination
+computer as separate files is a matter for future debate.
+
+If it were installed as tens or even hundreds of files, each of which had to
+be opened to decide whether it should be sourced in its entirety, that could
+prove very expensive on some systems.
+
+Alternatively, a master file could decide which of the individual completion
+files should be sourced. In that way, we wouldn't need to open extra files
+just to ascertain that the commands for those functions aren't on the system,
+anyway.
+
+A further alternative is that a build process be created, which would
+concatenate the various files into a single completion file, similar to what
+we have now. This option is my least favourite, because a system with a lot of
+packages installed currently has to deal with sourcing over 200 kB of bash
+code for each invocation of an interactive shell.
+
+An even better alternative would be if bash supported dynamic loading of shell
+functions (in the manner of zsh), but I don't believe there are any plans to
+add this feature.
+
+
+bash completion needs a better development environment.
+-------------------------------------------------------
+
+Currently, the bash completion project is managed by a single person: me. This
+is how it has been since its inception back in the first half of 2000.
+
+This way of working is now showing signs of severe strain. For quite some time
+already, I have been unable to devote enough time to the project and, as a
+result, it has suffered. In particular, releases in the past twelve months
+have been few and far between. The 20060301 release is the first in more than
+six months.
+
+Whilst there have been good reasons for my inability to devote more time to
+the project, it shouldn't actually matter whether or not I am available. For
+that reason, I am going to look at transferring the project to public CVS some
+time in 2006. Patches will then no longer find that I am a single point of
+failure, but will instead find their way into the code base via a small team
+of core developers.
+
+-- 
+Ian Macdonald
+Amsterdam, March 2006