GNOME OS BoF Minutes and Action Points

[Xan Lopez <xan gnome org>]

= GNOME OS BoF minutes =

Monday 30th July, A Coruña

== TL;DR ==

In case you don't feel like reading the transcript, here's a list of
the main topics discussed and the Action Points (APs) associated to
each one.

Those with assigned tasks should get to it ASAP and report to this
list (gnome-os-list) with progress updates. We'll create different
threads to discuss the details of each debate area.

* Application Development
 - Write an initial draft for the application bundle format. (Lennart)
 - Define requirements for applications. (Jon & Jimmac)

* Testable
 - Set up a build bot (Adrián, Andrés, Frederic, Andreas)
 - Web front-end (idem)
 - Buy more hardware (Andreas, Ebassi)
 - Minimum testing (?)
 - Define policies around build breakage (Release Team)
 - Send document explaining WebKit policies (Xan)
 - Send document explaining Mozilla policies (Ebassi)

 * GNOME 3 Core UX
- Define list of features and applications with priorities (Design Team)
- Proposal for libview (Federico)
- Bootstrap implementation of missing high priority applications (Design Team)
- Define and publish UX guidelines (Design Team)
- Define core set of technologies for core applications (Bastien & Cossimo)

* Pattern Language
- Federico to ask people about useful patterns they like.

* Touch & Mobile, new form factors
- Platform TODO list for touch (Bastien)
- Make the UX guidelines 'touch-friendly' (Design Team)
- List of reference touch HW (WeTab, Vivaldi, other), funding for
Touch-Box? (Bastien & Board)

* Others
- Extend Release Team in size and scope, try to drive and organize
medium term goals as exposed in the BoF (Release Team)

== Introduction ==

 * Juanjo and Xan laid out a summary of their talk (see:
   http://www.slideshare.net/juanjosanchezpenas/brightfuture-gnome)

 * Jon and Allan made a summary of their talk (see: ?)

We agree to use the main points in Juanjo and Xan's talk to
structure the debate, we start talking about application
development.

== Debate topics ==
=== Improve application development story ===

Lennart
 * How do app developers ship dependencies.
 * Need to have sandboxing - this is really important.
 * Need to have a testing story for apps - even if there is a GNOME
OS, there will still be derivatives. means we need to minimize our
APIs.
 * Requires a reference implementation.

Xan
 * How do we reconcile moving the OS forward with the requirement of
having API stability?

Lennart
 * We need to become faster rather than slower.
 * We have a couple of APIs that haven't changed - eg. kernel, X, dbus
 * Need to differentiate between API that we keep stable for a long
time and APIs that canchange more frequently (Kernel/X/DBus vs
GTK+/GNOME/etc)

Emmanuele
 * We can do it like apple - phased deprecation - a sliding window.

Patrakov
 * For that there would beed to be an "official" entity that does
official phased deprecations.

Lennart
 * But we have to support distributions/derivatives. We can let people
keep derivative API in their apps.

Colin:
 * GTK parallel installs. It is fine.

Jon
 * Application authors want to be informed about the experience their
users have.
 * They want their apps to be tested.

Xan
 * We don't have the resources to support two versions of the same
libraries. We very often phase out old versions pretty much
immediately after releasing a new one (GTK+ 3 vs 2).

Lennart
 * It should be up to application authors which versions they support
(and bundle the old versions of libraries)
 * This is what OS X does
 * The absolute minimum has to be shared.

Emmanuele
 * Example of games wanting long periods of support.

"Spider"
 * Apps do stagnate - they need to be able to stay in maintanence mode.

Xan
 * They can do that with the model that is being proposed.

Stef
 * We need to formalise which APIs are stable rather than it being implicit.

Lennart
 * It's not just about keeping the API stable; it's about knowing that
the code works. It's about testability.

Jon
 * Things I like about the sliding scale model:
   * It's already what we do today
   * Applications are constantly breaking because they don't know what
to target.
   * It's a contract model between us and application developers.
   * There's also a contract with the user - they know how long
something will last.
   * We have a 6 month app lifetime right now.
 * It makes a lot of sense.

"Spider"
 * We have no examples of how application developers can build and
ship dependencies.
 * They are currently baking their own solutions.
 * We can create some good examples of the static linking model.

Lennart
 * People won't write games for GNOME OS, they will write for libSDL.
 * Apps? libraries bundled and security is a likely complain of distros.
 * (mentions his talk contents) (deep technical summary)
 * Shipping disk images: apps that run in containers on their own
mounted squashfs filesystem.
 * The app would not see anything from the installed OS, it only sees
a few bind-mounted resources.
 * All the interfaces are somewhat complete in the kernel right now,
mainly used for virtualization of OS images.
 * There are a couple of bits to fill, just a matter of pulling all together.

Colin
 * Bundling dependencies isn't new, the challenge is sandboxing. The
whole chain has to be secure.

Owen
 * Security has to work at the user level - exposing functionality
that is useful to the user through the ui and API.

Lennart
 * Just because we can't get to 100% doesn't mean we shouldn't do 90%.

Owen
 * But if we only get to 20% we'll just create confusion.

Jon
 * We need to have a clear idea of what an application is, and we've
heard some of that here.
 * We need a clear list of issues we can target in the future. things like:
  * UX for installing an application.
  * Having apps self-contained.
  * The tools we provide to app developers.
  * Making sure that it works with our existing tools.
  * Understanding what we need to do now.
  * Need action items.
  * Installation UX.

Stef
 * Security allows us to get applications from different places rather
than having to check each one.
 * Security features should enable us to develop an application ecosystem.

Jon
 * What do we need to secure? Let's list it.

Stef
 * App wants to access pictures, online accounts...

Xan
[writes list of people developing standalone apps today]
 * What can we do to make this better today? We need to make anything
we come up with attractive to existing application developers.
 * [to Lennart] Is it possible to implement this plan, get it into
distributions, and convince existing application developers to use it?

Juan
 * This seems very ambitious, maybe trying to fix the entire linux ecosystem.

Garrett
 * This needs to happen for users.

Xan
 * We'll need an application format of our own if we want to do our
own OS, but it will need to work on existing distributions.

Roberto
* They have been developing a few apps on top of gnome for some years.
* They had problems to get the apps working in different distributions.
* Forr 3rd party developers it is a big problem not to have an stable API.

Owen
*  If we keep the core api really small - just gtk, glib etc -
application  authors will ask us how they actually make a real app [?]
* We do want to be talking about the GNOME SDK.

Xan
* He thinks the idea of having a very stable core os and a core ui
guaranteing some stability as well would partially solve roberto's
problems.

Jon
* Presents a list of questions que thinks we need to consider.
* From the developer point of view: how do I build the app? UX that we
are targetting? API that we are targetting? HW dependencies? How do I
get it to users? How do I protect my brand? How do I make money
writing the sotware? How do I update it?
* As user: how do I find out about an app? how do I get it? Is it
safe? What can the app do and see? For how long will it work? How can
I contribute?

Jon
* We need to have a definition of what an app is because this is the
only way of having a definition for the whole OS.
* The other important part is making gnome easily testable. We have
developers throwing code in git and never seeing how the result looks
like

"Spider"
* We shouldn't be trying to do everything distros are currently doing.
* We would be spending too much time in non-development tasks.

Action Points:
 - Write an initial draft for the application bundle format. (Lennart)
 - Define requirements for applications. (Jon & Jimmac)

===Testing===

* Colin gives a quick introduction to OSTree, with parts of his talk @ GUADEC.

Xan
* What are the goals?

Jon
* Wwo aspects:
 1) Build bot and automated testing.
 2) Contributors using as a developer environment.
* What can we do as a community to make it work?

Colin
* It's only a personal project and for hardcore hackers.
* It only gives you gnome shell and the terminal.
* Doesn't think that the os and applications should use the same build systems.

Owen
* Is it currently possible to test a patch against gnome-control-center?

Colin
* You can build stuff, boot into it, and it doesn't affect your
current system. That's what it does currently.

Xan
* A first goal could be to have a buildbot that uses ostree and
continuously builds and tests gnome.

Colin
* We would be just testing that it builds, for the moment.

Jon
* How can we make this useful? How can we make this a community
project instead of a personal one.

Colin
* Colin is working on the buildbot already.

Roberto
* Shouldn't we build a live image constantly so that people can download it?

Colin
* You don't want to download 600MB everyday and there are issues with
just downloading deltas.

Aday
* What happens with app developers?

Stef
* Why not doing the effort of having a full gnome with apps which is
testable, instead of just the base OS.

Colin
* We would need hardware to do the continuous build.

Owen
Two things were people could help ostre:
  * Help making the code compile
  * Creating a web interfaces that publishes the results of the build

Colin
[explanation of how ostree works and which output generates]

[conversation about how ostre output could be integrated with
something like buildbot, which is used by webkit and other projects
for continuous integration]

Colin
* Buildbot and getting everything compiling wouldbe be enough cause
some things have external dependencies that could still break.

Jon
Two problems we are having:
* We are increasingly depending on lower layers of the stack, and this
breaks the jhbuild model cause we cannot bould those dependencies.
* We don't have a policy for commits that break builds.

Jon
* There is the basic test of: (1) does it build? (2) can I log in? (3)
does it have network access? and nobody seems to be addressing this.

Xan proposes the following immediate goals for 'testable':
- buildbot
- web front-end
- minimum testing (gdm, network?)
(We could need to buy hardware for this)

Jon
* We need policies for when the build breaks.

Xan explains the way webkit does it (build.webkit.org and the policies
or rolling out patches)

People seem to agree with using policies similar to what webkit has.

Colin explains that he can tell the system which git commit to use to
compile, for each module, but Xan says that wouldn't solve the
problem.

Ebassi explains how mozilla integrates code, with different stages,
that could work better for GNOME than what webkit does.

"Spider" proposes an alternative way of doing it, with only one module
being updated and compiled and tested against the stable system.

Jon
Suggests 2 milestones for the next year:
- setting up a buildbot
- having the culture of responsibility for maintaining the build (next
GUADEC we don't get more feedback from GSoC students saying that they
cannot build the platform)

Action Points:
 - Set up a build bot (Adrián, Andrés, Frederic, Andreas)
 - Web front-end (idem)
 - Buy more hardware (Andreas, Ebassi)
 - Minimum testing (?)
 - Define policies around build breakage (Release Team)
 - Send document explaining WebKit policies (Xan)
 - Send document explaining Mozilla policies (Ebassi)

(Lunch break)

=== GNOME 3 core UX===

Allan
* Explains the vision of the Design Team about the core apps.
* Begins with 'Software'

Lennart
* Asks how the app is related to the extensions web page and boxes
(disk images).

The answer is that this is going to work with the packaging of the
distros for the moment, or even with webapps

[Discussion about if unifying all those things makes sense]

Owen
* Thinks we shouldn't unify things that don't unify naturally.

Allan
* Explains that the idea of 'Software' is quite flexible and could be
adapted to other things.
* He explains the apps under the Finding&Reminding category in the wiki:
  * Videos will be built on top of totem, Music nothing, Photos,
    Documents, Transfers. There is the long term goal of replacing the
    filechoser with a UI more similar to the applications.
* These set of core apps don't need to be very advanced. It is your
native way of accessing    content.

[Discussion about how realistic it is to think that the f&r apps are
going to be done in 18months]

One of the key goals or the apps is that they export search info to the shell.

[Discussion about if we should have 1 single app for chat+email+contacts]

Allan
* Finding & Reminding are the priority.

[Discussion about the resources and the current maintainers of other apps]

Jon
* Most maintainers answered that they are busy and don't have time for
upgrading UX. It is not either clear if they should maintain the old
look&field. So there is a need for more focus.

Cossimo
* One thing that is missing is the list of features that the apps need
to have in order to become a valid replacement.

Owen
* We need to be carefully defining what's not there yet and what won't be there.

Jon
* Even if we have a basic and very integrated Photos app there is
still room for shotwell.

The tools were rebuilt in gnome 2 for a document centric model
(evince, ego, etc.), part of that should be now a more sophisticated
tool, and part should be the viewer, that can be used from other apps
(preview+view).

Federico
* Talks about the disconnection between what the apps want to do and
what gtk offers developers.

[Discussion about the need of an installer vs 'sotware app' vs relying
on distros for that]

Xan
* Feels that we should really provide images with an installer.

Adrian
* If we are going to work with ostree, doing the installer is a step ahead

Colin
* There are two kinds of installers, one is the classical one, but the
other one is the ostree installer.

Adrian
* For some form factors the installer is more important.

[Discussion about the priority of doing the ostre-based installer]

[Discussion about how to install apps in the ostree installed system]

Jon
* At some point we should have tools as part of a gnome distro, as a
kit, extension or we need to discuss what.

Federico
* Some time ago there was a distinction between tools and hardcore
tools. We could do something similar, a lightweight development kit
and something more general. Apple had hypercard and people loved it.

SDK for app developers vs SDK for OS developers.

High level widgets and gtk

List of apps and priorities

Xan asks if in 2 years we could have this list of technologies and widgets.

Jon says that the guidelines will be available in less than 2 years.

[Discussion about what to recommend to 3rd party developers and
current status of language support]

We should generate documentation from gir instead of only for C as we do now.

Owen thinks that IDE and languages are something that will come later
and we have other tasks now more important.

[Long discussion about how to share high level widgets accross apps]

Federico things that 'pattern language' would be a solution for part
of the project.

Conversation about how some of the UX solutions that are being done
are hacks using gtk and clutter, and we need to get them right before
integrating them in gtk.

Action Points:
- Define list of features and applications with priorities (Design Team)
- Proposal for libview (Federico)
- Bootstrap implementation of missing high priority applications (Design Team)
- Define and publish UX guidelines (Design Team)
- Define core set of technologies for core applications (Bastien & Cossimo)

===Pattern Language===

[Federico does a presentation about (UI) pattern languages and form
patterns, he things we should have some better way of creating custom
widgets that still are themeable. Something that could use clutter and
gtk to achieve that. He mentions: Designinginterfaces.com]

Allan explains their current approach for patterns: higher level for
"kinds of apps" and smaller patterns for widgets.

Jon explains that they want to do something practical, not a 'book' as
there are a lot of books and HIG was essentially another book for
people to read.

Action Point:
- Federico to ask people for useful patterns.

===Touch and mobile===

Bastian explains that for the moment we are using the Wetab Desktop
with touch screen.

Top priority for GNOME 3 was *laptops* without being totally broken in
touch devices, specially since some laptops are touch enabled.

Today laptop, tomorrow tablet.

Design team trying to design for both things but they don't
necessarily are optimal for what it is coming.

[Discussion about how to give information to the system about which
device you are in.]

Mimo, possible hardware for touch tetisg: usb displays that are multitouch.

[Discussion about the need of gestures, touch and multitouch.]

Jon: We should be approaching it from a hardware capability approach,
not form factor. A tablet can be converted in a laptop attaching
things.

https://live.gnome.org/GnomeOS/Design/Whiteboards/Touchscreen
https://live.gnome.org/GnomeOS/Design/Whiteboards/Selections

Review design patterns to be if those are touch compatible.

Wayland coming forward is important cause the base requirements will
be the same than Android (EGL).

[Discussion about how much importance the touch priority has]

Getting hardware talk to the board.

Stand selling WeTabs with GNOME in next GUADEC.

Bastien
* A lot of work can be done from regular desktops (e.g. onscreen keyboard).

Xan
* Every detail matters applied to simplest touch-related bugs?

Action Points:
- Platform TODO list for touch (Bastien)
- Make the UX guidelines 'touch-friendly' (Design Team)
- List of reference touch HW (WeTab, Vivaldi, other), funding for
Touch-Box? (Bastien)

===Other===

How to organize all this? Many proposals and ideas, consensus evolves
towards the Release team being extended to take care of all this.

Jon thinks we need 1 person pushing this whole thing.

Federico can do some coordination and help with that.

Action Point:
- Extend Release Team in size and scope, try to drive and organize
medium term goals as exposed in the BoF (Release Team)