[Aptitude-devel] About the status and plans for aptitude

[Daniel Hartwig]

On 29 November 2011 07:58, Manuel A. Fernandez Montecelo
<manuel.montezelo at gmail.com> wrote:
> 2011/11/28 Daniel Hartwig <mandyke at gmail.com>:
>> I have a similar situation to yourself and began looking at this some
>> months ago.  There are many areas that need working on (error
>> messages/exit status, limitations of grouping policies, multiarch,
>> compatible behaviour with apt tools, etc.) along with requests for
>> minor changes.
>> [...]
>> I have started a list of stale bugs [1] which could be closed and
>> taken rough notes (currently tidying them) on the general state of
>> affairs with regards to the reported bugs.
>
> Great work.
>
> I think that many of them need (or would greatly benefit from) doing
> things directly as upstream, not just adding stuff/NMUs to the
> package.  Like adding/updating translations.

I agree that a regular stream of changes in the upstream git
repository is ideal, however, that requires access to a responsive
committer.  Alternatively, one could publish their own repositories
for working on major changes, which would at least provide others with
an easy way to follow and review them, and get the ball rolling again.

The BTS is also an issue, as the central source of information
relating to the state of the code it is critical to keep it updated.
I have performed some investigating, merging, and general cleanup, but
stopped short of actually closing [1] bugs.  At the time I preferred
to leave such to the maintainer so that he has the chance to review.
Now I think that it might be easier for everyone to just have those
`no longer valid' bugs closed with a brief note.  What do others think
about doing this?

[1] http://wiki.debian.org/BugTriage#Closing_unreproducible_bugs

> Did you think about that possibility, talked to Daniel Burrows about
> that, or gathered some opinion from other people about what to do?  Or
> are you not interested in the code at all?

I do have an interest in working on the code.  At the time I assessed
the situation I saw that a few people had already tried to get
Burrows' attention (the submitter of #497206 succeeded after more than
2 years) and there are numerous patches fixing minor bugs which could
have been uploaded but remain in the BTS, so I decided it probably not
worth bothering the man again.

> My main concern is that there's only one person taking care about
> development, which seem to have ceased to a halt lately, with nobody
> else stepping up.  If bit-rot starts to build up, and there's some
> major change in the assumptions on what the tool is built upon, that's
> easily the end of the project.

I think the only thing going forward is to just start working on the
code and BTS.  If a few of us can provide patches for some of the more
serious issues, at least that is something to work from and for people
to review.

This was, and remains, my plan of action.  Whether time permits much
activity is something we will find out in the future :-)


> But doesn't stuff like the description-less Package files, for example
> affect aptitude?

The details of that are (mostly?) handled by libapt, as long as the
API doesn't change I don't see that aptitude should be seriously
affected by this.  There are of course other changes, such as
multiarch [2], which will require more thought and work to sort out.


[2] The current tree/grouping policy mechanism has a number of
limitations which would make it difficult to separate specific
versions of a package by, e.g., archive, section (and maybe
architecture, depending on how multiarch support is handled).  See
halfway in to my comments [3] for some discussion relating to this.

[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603269#21