Ubuntu Monthly Update Cadence Proposal

[Matthias Klose]

On 01.02.2018 05:49, Bryan Quigley wrote:
> On Wed, Jan 31, 2018 at 10:49 PM, Robie Basak <robie.basak at ubuntu.com> wrote:
>> On Wed, Jan 31, 2018 at 10:39:00PM -0500, Bryan Quigley wrote:
>>> I see a few possible ways:
>>> 1.
>>>  * Packages that aren't part of a set that is coupled with others
>>> could be synced at any time
>>>  * Coupled sets of packages could be synced in a similar staggered way
>>> as directly uploaded packages
>>
>> Can you defined "coupled"?
> 
> Highly coupled - separate projects that should usually be safe to
> update independently.  However, if they were updated together it would
> be very difficult to determine which was at fault.
> 
> My classic example is you have a graphical issue after updating the
> Kernel and Mesa.
> 
> My ideal is it would be an evolving list - so if there are many
> regressions between two products we start viewing them as highly
> coupled.
> 
> It would also be a subset of packages that we consider in the critical
> path - so for example we'd likely want to define couplings for more
> packages in main then universe, etc.  We'd have to decide these
> priorities as a project.
> 
>> With a complex dependency tree, everything is
>> coupled. What happens when a sync gets stuck in proposed due to an
>> installability problem?
> 
> I have no idea, what happens today when that occurs?

I'd suggest that you do so called +1 maintenance work for a month full-time and
see what that means ...

>> Who are you proposing will do the additional work of the ongoing
>> management of all of this?
> 
> The hard part from my point of view is deciding as a project what we
> want to define couplings for, what the couplings should be, and what
> gets priority generally.

the python stack, the php stack, and others might be loosely coupled, but
throwing a few library transitions makes them highly coupled. couplings are
dynamic, not static.

Then you need to define "getting priority" as well.  I currently spend most of
my time fixing autopkg tests for transitions which I'm not interested in.
However it's necessary to fix these or you don't get any transition done.

> I definitely don't have all the answers - but I believe this would
> reduce the workload generally rather than make it worse.   I'm willing
> to do a lot of work to get this done (including changing roles), but
> in the end it will be up the various teams..

"up to the various teams". That currently doesn't work, and I don't see how that
will work in the future, given that teams are now more "focused", and leave a
lot to the "community". We have a lot of unowned stuff, and usually it the one
who sees blocking issues who has to clean up.

In your "Example Usage", you reserve one month for "Misc" and everything else,
and the remaining five months for everything else.  So you may be more recent
for 1% of the packages, but more out-of-date for 99%. Is that what users want?

What we are currently doing continuously would be stuffed into one month,
coupling 99% of the packages even more. I predict that the outcome of this month
would be a mess and not a stable basis that you can build upon.

Matthias