[Aptitude-devel] aptitude 0.6.9

[Manuel A. Fernandez Montecelo]

2012/7/1 Daniel Hartwig <mandyke at gmail.com>:
> On 1 July 2012 17:19, Manuel A. Fernandez Montecelo
> <manuel.montezelo at gmail.com> wrote:
>> but since aptitude is a
>> standalone and relatively straightforward package, accepting a new
>> minor version early in the freeze doesn't tend to cause big problems.
>
> The only problems I foresee are with the new command-line handling,
> which is much stricter about what is acceptable.  As mentioned, I have
> performed some testing with other programs (tasksel, cronapt) but do
> not usually use them myself.  The more likely disruption is to a
> persons personal scripts and/or usage patterns, which will have to be
> adjusted.  IMO the changes make the program more correct and I am
> willing to work to fix any potential breakage introduced.
>
> So Axel, Christian, please make a judgement call on this before
> deciding to upload, for the reasons Manual mentions below.  If these
> command-line changes aren't really appropriate at this stage of
> releasing (I don't really have experience to judge that properly) then
> we'll just leave this version until after Wheezy.

Christian just replied.

IMO you can easily convince the release team that allow the exception
*this early in the process*, as per:

http://release.debian.org/wheezy/freeze_policy.html
"3. fixes for severity: important bugs in packages of priority:
optional or extra, only when this can be done via unstable;"

This package is not optional/extra, but still, it's very early in the
process and there are a few important bugs fixed; while the changes
are not going to cascade into massive problems/bug-reports/changes
(e.g. new GCC or KDE/GNOME).

I'd say that the decision is mostly yours, if you think that the
changes are disruptive enough that it will cause you headaches to fix
them, and swearings of 3rd party packages/people affected by the bug.

Also, maybe you can consider to prepare some release without the most
dangerous changes.  As Christian said, non-invasive changes (like
translations, documentations, etc) are going to be allowed later.


>> a) upload soon and ask for freeze exception also
>> ASAP-with-some-days-of-margin (if RC bugs start to be reported against
>> that version, it will be difficult to convince release managers)
>
> To avoid entangling issues if the exception is not granted, should we
> get the exception (i.e. go-ahead from the release team) before
> uploading?

Ideally yes.  That's why I wanted to warn before uploading this
version: it's better to think about desired outcome, then ask
permission to release managers, then do -- rather than being entangled
in that situation without knowing.

Also, to warn you than from now on until the release, it's probably
better to hold all minor releases and work in long-term goals.

Cheers.