Blanket Feature Freeze Exception: Lubuntu's LXQt Transition

[Simon Quigley]

Lubuntu has transitioned from LXDE to LXQt for 18.10, thus making this whole release a new feature. We have a set TODO list[1] created by Lubuntu's Release Team (currently consisting of Walter Lapchynski and myself) but some of these are new features.

We can make the final release for this list, even the beta, but Feature Freeze cut a little too close.

My question is if Lubuntu as a flavor can request a blanket FFe to accomplish the items on that list in this unusual transition, which would apply to packages that only Lubuntu seeds.

Thanks.

UPDATE: here's a text list from the task:
New Calamares release ([ade] says it should be released on Wednesday
at the earliest; should bring LVM improvements galore)
T32: Calamares should let the user pick what applications they WANT to use
Full disk encryption T29
T54: Smart package removal

All of these are specific to Lubuntu.

[1] https://phab.lubuntu.me/T53

[Łukasz Zemczak (sil2100)]

I would be reluctant to approve a blanket FFe for this purpose, even for a non-LTS. We had some bad experiences in the past with blanket FFe's. What I would be willing to consider is a wider-range FFe for a selected set of features (which should be more or less similar). Would that be good enough?

If yes, we would need this bug to be updated with the list and details of the features (those that are breaking FF) that are planned to still land before release. Build logs are currently not required of course (since the features are probably still in the works), but an explanation for each of what packages will be updated, a quick look at potential regressions that *in theory* could get introduced by each and maybe a quick overview of the current progress. All this doesn't have to be too detailed.
This way the release team will know that there is a well defined plan of attack and what are the risks of all this not getting ready in time.

Also, do I understand correctly that these are *needed* for Lubuntu to actually be in releasable-state?

[Simon Quigley (tsimonq2)]

> I would be reluctant to approve a blanket FFe for this purpose, even for
> a non-LTS. We had some bad experiences in the past with blanket FFe's.
> What I would be willing to consider is a wider-range FFe for a selected
> set of features (which should be more or less similar). Would that be
> good enough?

Right, that's what the goal is here.

> If yes, we would need this bug to be updated with the list and details of the features (those that are breaking FF) that are planned to still land before release. Build logs are currently not required of course (since the features are probably still in the works), but an explanation for each of what packages will be updated, a quick look at potential regressions that *in theory* could get introduced by each and maybe a quick overview of the current progress. All this doesn't have to be too detailed.
> This way the release team will know that there is a well defined plan of attack and what are the risks of all this not getting ready in time.

The Phabricator task has intended features, but these aren't implemented
yet, so it's kind of hard to assess potential regressions. ;)

Namely:
> New Calamares release ([ade] says it should be released on Wednesday
at the earliest; should bring LVM improvements galore)
> T32: Calamares should let the user pick what applications they WANT to use
> Full disk encryption T29
> T54: Smart package removal

> Also, do I understand correctly that these are *needed* for Lubuntu to
> actually be in releasable-state?

Yes.

[Łukasz Zemczak (sil2100)]

Could you update the bug for it to state the features that will be handled by the FFe?

[Łukasz Zemczak (sil2100)]

Ok, I think this is good enough, thanks. I approve of the FFe for the listed changes in the description. Green light!

[Simon Quigley (tsimonq2)]

Thank you!