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