[pacman-dev] Organization: pacman todo and timeline
aaronmgriffin at gmail.com
Fri Dec 22 01:20:54 EST 2006
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:
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
More information about the pacman-dev