On 29 November 2011 07:58, Manuel A. Fernandez Montecelo <[email protected]> wrote: > 2011/11/28 Daniel Hartwig <[email protected]>: >> 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 _______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
