[FFe] standing freeze exception in vivid for Ubuntu Touch-specific packages

[Łukasz Zemczak]

Dear Release Team,

I would like to request a blanket FFe wrt Ubuntu Touch, for those packages that are part of Ubuntu Touch and Ubuntu Desktop Next but not part of Ubuntu Desktop. TTBOMK, the packages that are different between the two are not otherwise used in other flavor images.

I've assembled a list of 200 source packages, included inline below, that would be affected by this. The script used to generate the list is located in ubuntu-archive-tools: `generate-freeze-block -u ubuntu-touch ubuntu-desktop-next`.

For the vast majority of these packages, there is no expectation of freeze-breaking changes; but since there is a high probability that some critical features will not be landed by Feature Freeze for some subset of these packages, I think it makes sense to deal with these as a whole rather than requesting exceptions package-by-package or feature-by-feature.

I have added a few tools packages that are also will require changes, such as phablet-tools and goget-ubuntu-touch - as those are basically only used for touch purposes. The "android" package has also been added which isn't installed on the seed per say, but is used to build the image and provide the android part of the Touch image.

Then I also added the apparmor-easyprof-ubuntu and ubuntu-download-manager which are part of our Ubuntu Touch images (and not part of Ubuntu Desktop) but are also part of some other flavors. Those might be useful to have an FFe since they're used extensively in Touch. They are here up for discussion and might be removed from the list.

Please note that, similarly as before, there is no mir package in this exception as it is currently partially used by Ubuntu Desktop. The Mir team has informed us that they will be only uploading bugfixes so a special exception is not required.

The list:

abootimg
account-polld
address-book-app
address-book-service
android
android-tools
autopilot
autopilot-gtk
autopilot-legacy
autopilot-qt
bluetooth-touch
camera-app
capnproto
ciborium
connectivity-api
content-hub
contextlib2
cordova-ubuntu
dbus-cpp
dbus-property-service
dee-qt
dialer-app
dutch
espa-nol
eventstat
fbset
forkstat
friends
gallery-app
goget-ubuntu-touch
gst-fluendo-mp3
health-check
history-service
hspell
hunspell-ar
hunspell-fr
hunspell-ru
igerman98
indicator-display
indicator-location
indicator-network
indicator-transfer
initramfs-tools-ubuntu-touch
ipolish
ispell-czech
language-pack-touch-ast
language-pack-touch-bg
language-pack-touch-bs
language-pack-touch-ca
language-pack-touch-cs
language-pack-touch-da
language-pack-touch-de
language-pack-touch-el
language-pack-touch-en
language-pack-touch-es
language-pack-touch-eu
language-pack-touch-fi
language-pack-touch-fr
language-pack-touch-gd
language-pack-touch-gl
language-pack-touch-he
language-pack-touch-hu
language-pack-touch-id
language-pack-touch-it
language-pack-touch-ja
language-pack-touch-ko
language-pack-touch-lt
language-pack-touch-lv
language-pack-touch-ms
language-pack-touch-nb
language-pack-touch-nl
language-pack-touch-oc
language-pack-touch-pl
language-pack-touch-pt
language-pack-touch-ro
language-pack-touch-ru
language-pack-touch-sk
language-pack-touch-sl
language-pack-touch-sr
language-pack-touch-sv
language-pack-touch-tr
language-pack-touch-ug
language-pack-touch-uk
language-pack-touch-zh-hans
language-pack-touch-zh-hant
libfriends
libhybris
libjsoncpp
libmediainfo
libphonenumber
libpinyin
libqofono
libsynthesis
liburcu
libusermetrics
libzen
location-service
lxc
lxc-android-config
maliit-framework
maliit-plugins
media-hub
mediaplayer-app
mediascanner2
messaging-app
mtp
myspell-hr
myspell-pt-br
myspell.pt
net-cpp
notes-app
nuntium
ofono
ofono-qt
pay-service
phablet-tools
platform-api
poppler-qml-plugin
powerd
powerstat
presage
process-cpp
pyjunitxml
python-evdev
python-extras
python-fixtures
python-mimeparse
python-testscenarios
python-testtools
python3-dateutil
qdjango
qmenumodel
qml-friends
qt3d-opensource-src
qt3d-opensource-src-gles
qtbase-opensource-src-gles
qtdeclarative-opensource-src-gles
qtkeychain
qtlocation-opensource-src-gles
qtmir
qtmir-gles
qtmultimedia-opensource-src-gles
qtorganizer5-eds
qtsensors-opensource-src
qtsystems-opensource-src
qtubuntu
qtubuntu-camera
qtubuntu-gles
qtubuntu-media
qtubuntu-media-signals
qtubuntu-sensors
qtvideo-node
qtxmlpatterns-opensource-src
reminders-app
signon-apparmor-extension
smemstat
softcatala-spell
subunit
sync-monitor
syncevolution
tcptraceroute
telepathy-ofono
telepathy-qt5
telephony-service
thumbnailer
tinyxml2
tone-generator
trust-store
u1db-qt
ubuntu-app-launch
ubuntu-html5-theme
ubuntu-keyboard
ubuntu-location-provider-here
ubuntu-push
ubuntu-push-qml
ubuntu-settings-components
ubuntu-system-settings
ubuntu-system-settings-online-accounts
ubuntu-touch-customization-hooks
ubuntu-touch-meta
ubuntu-touch-session
ubuntu-ui-extras
ubuntu-ui-toolkit-gles
ubuntuone-credentials
umockdev
unity-api
unity-notifications
unity-scope-click
unity-scope-mediascanner
unity-scope-scopes
unity-scopes-api
unity-scopes-shell
unity-system-compositor
unity8
unity8-desktop-session
urfkill
usensord
ust
xpathselect
zmqpp

Additional propositions:

apparmor-easyprof-ubuntu
ubuntu-download-manager

[Iain Lane (laney)]

Hi,

On Thu, Feb 12, 2015 at 11:43:23AM -0000, Launchpad Bug Tracker wrote:
> You have been subscribed to a public bug by Łukasz Zemczak (sil2100):
> […]
> For the vast majority of these packages, there is no expectation of
> freeze-breaking changes; but since there is a high probability that some
> critical features will not be landed by Feature Freeze for some subset
> of these packages, I think it makes sense to deal with these as a whole
> rather than requesting exceptions package-by-package or feature-by-
> feature.

Hmm, this is saying that some unspecified package(s) may or may not add
some unspecified features at some point this cycle, and because of that
we should give a pass to all packages.

I think this is the third cycle where such a blanket exception has been
requested now - do you think there's any chance that touch development
is going to align with the Ubuntu release cycle in future? If not, we
might be better off thinking up a process which works for everyone.

Cheers,

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

[Łukasz Zemczak (sil2100)]

Hey,

Sadly with the current processes setup it's not an easy thing to coordinate. Touch development and schedules are tightly bound to client requirements which means developers need to be able to work on feature requests when needed. We could of course work-around that by simply moving all active development away from the main archives and work on a derived one (like ubuntu-rtm and some sub-series) instead, but this would once again introduce yet another layer of backporting needed. We could also do the split at the moment of a feature freeze, then do all development on the derived distribution instead (maybe only backporting stability fixes) and then sync everything up to the new development series once it opens. But making of such synces is not easy. But yeah, there might be some other ideas as well.

For this cycle though I would like to request such a blanket FFE once again.

[Scott Kitterman (kitterman)]

If you don't get the blanket FFe, how many FFe requests do you realistically
expect to file?

[Łukasz Zemczak (sil2100)]

It's really hard to say and guess, since it's impossible to plan too much ahead in this case right now. Seeing how frequently designs are changing for Unity8 and the touch core-apps this might be potentially a lot of FFe's. The system is still evolving and with the coming work on the new phone I would expect many many occasions where developers will be required to change existing functionality as per client request (due to new screen sizes and phone parameters etc.). The last cycle, after feature freeze, so many components have been changed that the blanket FFe really made things much easier for both the release team and the actual developers.

[Scott Kitterman (kitterman)]

At some point, AIUI, Unity 8 will be the default Ubuntu desktop experience as
well. When that happens, I think such a blanket exception will be out of the
question.

As a step in that direction, how about we start this cycle without the
standing freeze exception and see how it goes: how many FFe are needed, how
quickly they are processed, etc. Getting an FFe approval isn't a prerequisite
to doing development work, just to landing it in the archive, so unless the
requests lag for some time, I doubt this will have an impact on development
velocity.

[Łukasz Zemczak (sil2100)]

Hey Scott,

For me that sounds like a plan. I would still prefer to keep this bug open in case we find that it's necessary and then re-consider it once again. I'm only a little bit worried about the bits that need to keep changing related to hardware support, so components like android and others. The blanket FFe would certainly make things easier here.
But it seems that for the next 1-2 weeks we'll anyway halt on normal feature development (besides hardware enablement) since we're aiming on getting vivid touch stability into a much better state.

But I would like Steve to comment here as well. Steve, what do you think?

[Scott Kitterman (kitterman)]

Leaving the bug open is fine. I'm open to re-assessing if lack of the standing
freeze proves to be problematic.

[Martin Pitt (pitti)]

Obsolete, closing.