[pacman-dev] Organization: pacman todo and timeline

[Aaron Griffin]

Ok.  So I think it's time i get this written up.

Right now, I plan on getting pacman3 into [testing] ASAP.  There were
some NoUpgrade issues (previous thread) and they have been "handled"
for the time being.

This means that stability is the single most important thing.  So, I
need any and all available people to test this out:
http://archlinux.org/~aaron/pacman/

I will periodically push new versions here based on changes which will
most likely be discussed on this list.

Now, beyond that, I have been keeping a "TODO.aaron" file separate
from the other stuff.  There is alot of reorganization I'd like to do
before I get moving on any newer (complex) features.  First and
foremost, having functions which are over 100-200 lines tend to imply
that something needs to be split out.  Alot of these functions can be
split out into logical units.  For instance, _alpm_add_commit
(lib/libalpm/add.c) contains a large chunk of lines for determining /
checking md5sums.  This would make alot of sense as a separate
function which would, say, determine the ACTUAL output file.  This is
just an example.
If anyone needs something to work on on the C level, I would HIGHLY
appreciate some refactoring help here.  Feel free to post any and all
suggestions - nothing is stupid.

So as for a timeless timeline, the plans are as follows:
* release pacman3 to the masses
* accept bug reports and fix what people complain about a lot
* refactor the libalpm / pacman internals and remove some of the overlap
* feature time (I have about 3 or 4 really good ideas)

Unordered, but also important:
* new backends (selectable at runtime?)
* make the public libalpm interface easier to use