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

[Daniel Hartwig]

Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com> wrote:
> If for example it's decided that we shouldn't touch the current
> repository for the time being, then maybe it's better to clone it
> elsewhere and fix stuff without more delay, and then it would be
> pulled by dburrows when he becomes available again.  I think that this
> way of doing things would be less intrusive (+1) and would allow us
> and maybe other interested people to tweak and learn about the code
> without causing trouble to the real repository (+1), but with the
> effect that we would not be able to release directly and thus still
> not making easier the process of triaging bugs, etc.

There is currently a clone on gitorious that hosted a QT development
branch.  However, given my suggestion below, I think we can
unintrusively work on the alioth repo.

Either way, I agree that it is best to begin such efforts soon.

> On Saturday 31 Dec 2011 09:45:20 Christian PERRIER wrote:
>> I think it would be nice to have you guys able to commit in the
>> repository but I can't do this now as I'm not admin for the project.
>
> Good.  Is it OK for you, D. Hartwig?

Yes, and this is preferable to creating a mirror somewhere.

In support of this, especially if D. Burrows is not involved at this
point, I propose to follow a strict policy for commits:

1. Master and debian branches for simple bug fixes and maintainence
   only.

2. Separate branch for each fix which requires extensive changes, to
   be peer-reviewed and merged only as appropriate.  (Small changes
   can stay on the BTS for review).

   Branch names like: bug-341434-alt-configs

3. Feature branches

   : wip-multiarch

Especially 2 and 3 are easier to work with than either a series of
large patches on the BTS or such branches being in a mirrored
repository somewhere.

I have no idea how we will go in recruiting peers to review the
work...  Are there many interested developers following this list?


To give an idea of the immediate changes I would push:

There are some two dozen bugs currently tagged `patch' which after
evaluating I consider suitable for comitting to the master branch.
Some others are not suitable at all (due to changes in the code or
just poorly done patches) -- these I shall untag shortly -- while
others could be committed to separate branches or just remain in the
BTS (for really small fixes).

There are various changes to the packaging requested (#263318,
#445125, etc.).  Most of these are minor changes suitable for the
debian branch.

Proper multiarch support is very important before Wheezy freeze, which
is proposed to be only a few months away.  Dpkg and apt support is
becoming quite mature.  This is really a topic for another day.

I have two local WIP nearing completion which address over a dozen
bugs relating to locking and command line arguments/exit status.  The
changes to the code are extensive and certainly would require review
before being merged.


>
>> I'll focus on the l10n stuff in the upcoming days. I was indeed
>> wondering whether I should do it..:-)
>
> I saw that you went ahead, great!

Indeed this is quite useful.  Thank you.

There are many bugs with minor corrections to the strings (missing
newlines, etc.) and docs (paragraphs in the wrong place, ...) which I
think will be easier to fix after apply all outstanding translation
updates.  This way it is possible to fix the string and it's
translations all at once, without worrying that the changes will be
undone or lost in a translation update.

Consider #652419 (some prompt strings miss trailing spaces, etc.)
where the changes required are trivial and translations could be
updated at the same time as the main strings.  Is this considered
something which is ok to do or should all updates to the translations
be done by someone who knows the language in question?

Either way, I think it best to apply all changes affecting
translations sooner rather than later so that translators can do their
work in one pass, rather than having to keep following a series of
changes over the next several months.