Comment 8 for bug 1714019

On Fri, Sep 1, 2017 at 2:07 AM, Steve Langasek
<email address hidden> wrote:
> https://bugs.launchpad.net/ubuntu/+source/unattended-
> upgrades/+bug/1714019/+attachment/4942097/+files/unattended-
> upgrades_0.93.1ubuntu8-to-0.96ubuntu1.patch appears to be a reversed
> patch, and doesn't have a changelog entry for 0.96ubuntu1.

I have fixed the patch it was reversed indeed, but contains the
changelog, just not at the beginning like it is usual for diffs.

>
> Which parts of this change is it that you believe violate feature freeze
> and require an FFe? (Bugfixes do not require an FFe.)

There are some changes which don't fix bugs but can be seen as
improvements, like:
   * Update the signal used to SIGTERM in the documentation
   * Fix incorrect example for Update-Days.
   * add pep484 type hints
  ...

I also prefer being cautious and asking for such permissions even they
may not be strictly required.

>
> If an FFe is required for the merge, why do a merge rather than cherry-
> picking of the specific bugfix changes?

The part which would be cherry-picked is like ~90% of the changes if
we want to have u-u be in a reasonably good shape in Ubuntu and having
the big delta was painful enough to maintain already.

I aimed at having a sync but dropping/integrating LP: #1649709 needs
more discussion at least with infinity, it seems.
See: https://irclogs.ubuntu.com/2017/08/01/%23ubuntu-devel.html ,
starting from 11:06

>
> >From NEWS.Debian, I understand that a key change is to turn on the
> minimal steps handling by default. What is the impact of this change on
> the time it takes to do a typical update? Are we in any way increasing

I have not tested the additional time because without enabling minimal
steps u-u can't be stopped gracefully after it started the actual
upgrade.
Thus i saw no decision point here.
It is worth measuring the impact and checking if we can speed u-u up
in that area, but IMO this optimization should not delay the
acceptance of this upload.

> the risk of an unclean shutdown due to a laptop running out of battery
> during the upgrade, where this wouldn't have happened if we weren't
> doing minimal steps?

When InstallOnShutdown not set apt-daily-upgrade.service does not run
u-u when running on battery:
http://sources.debian.net/src/apt/1.5%7Ebeta2/debian/apt-daily-upgrade.service/#L4

When InstallOnShutdown is set this is a valid concern and thank you
for raising it.
I've just prepared a fix to mitigate this risk:
https://github.com/mvo5/unattended-upgrades/pull/75/commits/fd65bb54556624aacac5212d9d21e3a66df251c3
>
> debian/postinst changes the minimum version at which installinit upgrade
> handling is applied, and will be reapplied to systems which have the
> existing artful package installed. Could this be a problem? E.g., does
> this forcibly override the user's preference on upgrade if they have
> disabled the service in systemd?

I have not changed the version check compared to 0.93.1ubuntu8, thus I
see no problem in this area related to FFe.