Bug#924523: unblock: plinth/19.2

[Sam Hartman <hartmans@debian.org>]

>>>>> "Sunil" == Sunil Mohan Adapa <sunil@medhas.org> writes:

    Sunil> On 23/04/19 3:44 am, Ivo De Decker wrote:
    >> Hi,


    Sunil> However, there were still issues that we felt needed fixing
    Sunil> for a stable release. Some of these fixes are workarounds for
    Sunil> issues that were not fixed in other packages (such as #919517
    Sunil> and smooth upgrade failures in other packages).

    Sunil> Pretty much all the changes between 19.1 and 19.2 (version
    Sunil> increment is because freedombox is a native package) were
    Sunil> focused on Buster release during which we were not adding
    Sunil> extra features.

I'm speaking as an individual who has been following freedombox in the
background for years and who has had to make decisions like what the
release team does in other projects.  I'm *not* speaking as the DPL even
a little bit.  And even if you follow my recommendations here, the RT
might be more conservative than you hope for.
 

In order to maximize the number of changes that can get in between 19.1
and 19.2, I recommend that you spend some time to make the release
team's job easier.


I'd recommend going through each commit, explaining why it meets the
release guidelines.

If it doesn't and you want to argue for an exception, be clear about why
that specific change is safe.  As an example, if one of your functional
tests covers it, say that.

Your job is to make sure that the release team can easily see in one
place why the change is worth the risk and that you've thought about it
explicitly and considered the option of dropping that change.

And you probably will find changes that it's better to drop.
Regardless of whether you missed the deadline by hours or whatever,
we're talking about  this issue now not then.  There's less time between
now and the buster release than there was back in March, and that means
the risks are higher.  And so in arguing for a change you need to
account for that increased risk.

And because the RT has a lot of work to do you need to make it easy for
them.  They are going to have to review each change, so you'd better do
that first:-)

As an example, from your original bug:

  - Upgrade changes: Complementary to unattened-upgrades, assist
    non-technical  
    FreedomBox users to automatically upgrade from older versions of
    bind,      
    tt-rss, firewalld, libpam-modules, and openvpn. This helps users
    migrating  
    from Stretch. Another change was to avoid a conffile prompt within          
    FreedomBox itself to ease future upgrades.                                  

This sounds like an important bug: you ran upgrade testing from stretch
and ran into an issue that impacted users.
If there's not a bug number, you want one probably.  If there is, make
sure it's marked important and it's clear why.