19.10 "final freeze" impact

With the freeze now in place, what are the chances of the session restore bug being fixed in the initial 19.10 release? (That is, assuming the devs have time to bisect it and fix the regression).

Assuming the answer is "none at all" at this point, would the fix eventually make its way out whenever it's ready without too much of a headache, or would it have to go through so much "paperwork" that Wimpy/whoever would just leave it for 20.04 instead? Do the Ubuntu Overlords (I have no idea what that group is actually called :P) treat regressions, bugfixes, and features differently, or are they all just "changes" as far as they're concerned?

These "Ubuntu Overlords" would probably be the Ubuntu Release team and SRU team. Stable Release Updates (SRUs) are the requests to make changes into the archive.

This quote from the Ubuntu development mailing list answers the question of "what happens now?"

The current uploads in the queue will be reviewed and either accepted
or rejected as appropriate by pre-freeze standards, but anything from
here on should fit two broad categories:

  1. Release critical bugs that affect ISOs, installers, or otherwise
    can't be fixed easily post-release.

  2. Bug fixes that would be suitable for post-release SRUs, which we
    may choose to accept, reject, or shunt to -updates for 0-day SRUs
    on a case-by-case basis. This second case should have SRU-style
    bugs filed with the appropriate template, referenced in changelog.

-- https://lists.ubuntu.com/archives/ubuntu-devel-announce/2019-October/001267.html

After the release, it's the usual SRU procedures, which covers what they'd accept.

I'd imagine the mate-session bug is one that MATE developers would fix, and likely will be included alongside a new release of MATE (e.g. 1.24) which probably won't qualify for a SRU because of all the new features / changes. Unless of course, that specific bugfix is patched in the current 1.22 package or exceptions are made. Depends how severe the bug is.

Thanks. "Severity" is basically going to come down to the whims of the SRU team then.

To me, this is a deal-breaking regression, and I'm going to have to reinstall either 16.04 or 18.04 on that machine, because 19.04 will lose support before 20.04 is released.
To someone who doesn't use session restore though - which they probably don't, since Unity didn't even have it! - it's a trivial bug that doesn't matter at all.

I guess I'll just have to hope.

I skimmed the code quickly just now, and the actual save/load code is so simple that it's clearly correct. That's unfortunate, because it means the bug is either in meta_window_get_geometry when saving the session, or in an unrelated area after when loading it, and either way the regression is a side-effect of Something Else.
I can probably find and fix the actual bug fairly quickly myself, but I don't have the time to deal with the startup overhead of actually getting the thing to build - I've been down this road before with libraries etc we've used at work, and I know what a black hole for time it invariably is. :frowning:
(And, jep - 30 minutes after cloning the repo, the typical issues with build systems requiring root and/or failing to acknowledge local paths for includes etc are as present as expected - but that's a topic for a different thread).

Thanks for answering the question as quickly and completely as you did: it's not the answer I particularly wanted to hear, but I was expecting that, and it's certainly not your fault. :slight_smile:

it means the bug is either in meta_window_get_geometry when saving the session

Woah, okay I can see what the problem is. Thanks for pointing out your findings. I just saw the bug and to me this is very clearly a bug introduced with the new invisible borders in marco.

I've just assigned the bug to myself of launchpad to take a look, but yeah, this is the kind of bug that can be backported when fixed, and maybe SRU'd post-release (but definitely not during the current freeze)



A PPA would certainly be a lot better than nothing. I can understand not allowing new features, but if a bug like this can't be SRU'd then the process is simply broken to the point of uselessness, and Ubuntu needs to have a hell of a lot more to the testing period than two weeks if they're not even going to allow high-impact fixes once a release is made. eesh...

Honestly I said maybe in part because I don't knowhow the SRU process
works. I think you need to have a confirmed bug in launchpad, and the
fix needs to have been released already. Or something. I've never taken
part in that process...

Backporting in upstream MATE, however, that I can do myself. Once I send
in a fix and it gets reviewed and approved, I merge it and cherry-pick
it into the version branch (1.22 in this case). If anyone is interested
in it immediately (e.g. Ubuntu MATE 19.10), then I can tag a new release
and then the Ubuntu MATE maintainers team (i.e. Martin) takes over with
the SRU process and whatnot.

If I think it's a fix for a critical bug, then I'll pester Martin about
it and he takes it from there. Usually, though, he's the one pestering
me about fixing bugs :rofl:


Thanks. I built marco over the weekend (1.22.2 specifically, not HEAD), but many of the people I support have no hope in hell of being able to install it without at least a PPA, and most I doubt will manage it at all unless it comes through the default channel.

I'd you'd like, I'll be happy to nag him about it on your behalf til he killfiles me. :stuck_out_tongue: