Flock 2017

Flatpak is a new system for distributing graphical applications with isolation from the host operating system. Dependencies can be bundled with applications, or shared between different applications via a "runtime". Applications can be sandboxed to have only limited access to the user's data via a system of "portals", which let the user see and control what data is being accessed.

The introduction of Flatpaks into the Fedora ecosystem will provide benefits to users including secure sandboxing of applications, reliable application upgrades without rebooting, and the ability to run versions of applications from newer or older versions of Fedora. Flatpaks will be the primary delivery mechanism for Fedora modularity on the desktop, providing the ability for applications to be updated in Fedora as new upstream versions are released, without having to coordinate dependencies across the entire distribution.

This talk is targeted at Fedora packagers. It will provide a technological overview of Flatpak, describe new features that are being added to Fedora infrastructure to support building Flatpaks, and walk through the process of creating a module and Flatpak from an existing Fedora package.

In the last few years, the scope of automated testing in Fedora (by several different automated testing systems) has increased quite a lot. As a packager, you may not be aware of all the testing that goes on in relation to your package builds and updates, and how you can interpret and benefit from the results. In this session we'll go over the test systems Fedora uses, when and how your packages will be tested, and how you can find, examine and interpret the results.

A brief overview of what we're aiming to achieve with Fedora IoT SIG, a current status of where we are and where we're going and a quick start to getting it running on a device.

96Boards is a range of hardware specifications developed by Linaro and the 96Boards member companies to make the latest ARM-based processors available to developers at a reasonable cost, in a standard form factor. Since it's launch in 2015, a strong community has surfaced and fed into our growing ecosystem. This talk will summarize some of 96Boards' greatest milestones and achievements, while focusing on the future growth of our vibrant community. From 96Boards Distribution and Mezzanine enablement to creating and maintaining open support and diverse community outreach channels, 96Boards has always tried to promote a lasting and positive experience for anyone involved.

www.96Boards.org

Ever wondered why we do the legal voodoo that we do (do) so well? I'll give the 15 minute lightning talk that I did at FOSDEM on Fedora Legal, and then let you pepper me with questions. I promise to try not to answer 'it depends" and "no comment" unless I absolutely have to.

"Will Woods introduces Project Weldr, which is exploring new ways to
build custom images from RPMs. This will be a high-level talk about the
project goals, the results of our research, a demo of our prototype, and
some proposed changes to the Packaging Guidelines to enable innovative
new work in Fedora. Contributors familiar with the technical details of
packaging and image build tools are especially welcome."

Continuous integration aims to ensure broken changes do not affect users, packagers or maintainers. Continuous delivery aims to ensure broken changes don't get released.

At the center of CI is tests. I'd like to show you consistent simple ways to add tests to your dist-git package using Ansible. We'll walk through how to test an installed package, a Fedora Qcow2 image, as well as a docker image and module.

We'll look at how to turn on gating for your package, similar to GitHub, so you can get feedback immediately. This saves packagers extra work having to fix bugs later down the line.

With all the new cool combinations of content (RPM packages, modules, Docker images, ...), the dependencies between artifacts are starting to be much more complex. When you update a .spec file, you need to remember to rebuild modules containing that .spec file. When you rebuild a module, you need to remember to rebuild containers that include that module. This is a lot for anyone to handle!

Fortunately, we have an answer - the Freshmaker system. In this talk, we will cover:

- What are the problems Freshmaker is trying to solve for you.
- How Freshmaker works and interacts with other Fedora services.
- What is the current state of implementation and what are the future plans.

Have you ever noticed the automated test results in Bodhi? The Fedora QA team has done some great work, running lots of automated tests when you file a new update. Today those test results are aggregated in ResultsDB and appear in Bodhi when you file your update – so where do we go from here? In this talk, I will introduce two new services we are working on: Greenwave and WaiverDB. Greenwave is a service that Bodhi will query to decide if an update is ready to be pushed, based on its test results. And WaiverDB is how we deal with test results that are wrong. We'll cover:
- Why we need a service like Greenwave, and what problems it helps us to solve
- What happens when a test goes bad? – why we also need WaiverDB
- Oh no, not more red tape! – how Greenwave will help enable more automation in future, through Freshmaker
- How Greenwave works under the hood, and how it relates to ResultDB and WaiverDB
- How to define a policy in Greenwave, and how to waive a test result in WaiverDB
- Where we are at today with the implementation and our plans for the future

To be effective as a packager, you need to follow your upstream projects and give these upstream communities some feedback on their new or upcoming releases.

In this talk, we'll see ways to automate this feedback loop through continuous packaging and CI.

Fedora documentation is struggling to keep up with new developments. New docs don't get written, and existing docs are becoming obsolete. New contributors don't know where to start, and long-time Docs Team members are stretched thin.

This session will focus on teaching contributors to adapt existing docs and write new docs using a new format: modular units of content based on user stories. This will help reduce the amount of docs (easing the maintenance burden) as well as better serve users (targeting specific user stories).

A workflow based on easy-to-use templates will be introduced to allow quick on-boarding of new contributors and easy creation of both new docs and adaptation of legacy docs.

Following a brief intro and explanation of best practices, we will work with real docs to create tangible results and get people familiar with the process. The aim is to get the ball rolling and encourage contributors by making Fedora docs fun again.

What you need to know to get ready for this workshop

Diversity Team hack-fest - We will like to target two major milestones during diversity team hack-fest -
a). Planning of Diversity Events
b). Diversity team interaction with other Fedora sigs/groups

Agenda
======
Diversity Team did a great job in order to carry out Fedora Women Day and LGBTQA events. We want to do more such events annually, in order to target
more minority groups in future as well. This should be one of the main ongoing, always rolling and continuous activity for our team.

We identified few such events, which we would like to organize in a year -
---------------------------------------------------------------------------------------------
a). Fedora Women Day - In September
b). LGBTQA - May 17 -https://en.wikipedia.org/wiki/International_Day_Against_Homophobia,_Transphobia_and_Biphobia
c). Disabilities - December 05 -https://en.wikipedia.org/wiki/United_Nations%27_International_Day_of_Persons_with_Disabilities
d). FLISoL - Fedora Diversity presence for "Latam-Hispanic" group -https://en.wikipedia.org/wiki/FLISOL
e). Fedora Diversity Day - FAD for diversity team

As diversity team is a very small team of few core members only, so we want to take feedback from other fellow Fedora contributors as well.
This hack-fest will help us collaborate with other teams in Fedora - Ambassadors, Marketing and CommOps.
We would like to collaborate with these teams for having inputs and suggestions for diversity events and would like to take help to organize these events world wide on large scale.

Inputs
=====
Organizers - This hack-fest will be lead by Amita Sharma and Justin Flory.
Team Members - It will be great to have Jona and Bee in the same room for this hack-fest.
Others - In order to make it real success, we would like to have Bex, Few Ambassadors from different regions (robyduck, sumantro, Jona, Justin, x3mboy) and Paul Fields from magazine team. We have contacted them via mail for joining our session. Also, I am planning to do a blog post to invite more people to join the session on fedora community blog.
Logistics - White board with some markers.

Activities
======
a). Review the existing events on the list and revise he event planning according to the feedback from everyone.
b). Coming up with a flowchart which can fit most of these events and can be defined easily. For example - N days before we need to publish an article
for event, then we need to do next activity, then next...
c). How many regions can be targeted for the event X and how to co-ordinate among regions. Who all from ambassador team can take up the initiative and
whom we can contact for the event X for a specific region.
d). Inputs for activities for every event which will make them unique and remarkable.
e). Format of the posts - Event planning posts, Event Schedule post, Event Report post etc.
f). How to evaluate the success rate of the events.
g). Budget Requirements and what best we can do without depending much on budget.
h). Identify any other significant day to celebrate as a Fedora diversity event.

Outputs/ Outcomes
=============
a). Annual Diversity Events in Fedora Community at large scale, world wide.
b). Defining Diversity events strategies.
c). Defining Time lines for the events.
d). Open platform to reach out to the other Fedora sigs/groups for feedback
and suggestions for the events.
e). Craft event campaign to celebrate and acknowledge the diversity in
Fedora community.
f). Define reach of events.
g). Create focus groups in different regions to pull out the events.
h). Identify strength and shortcoming of the event planning.
i). Improve visibility and awareness among other Fedora contributors.

Impact on Fedora Mission
====================
[Fedora Mission - https://lwn.net/Articles/720055/ ]
a). Improve and support diverse range of contributors and create more
inclusive space in Fedora.
b). Part of our Fedora mission says " For community members to build
tailored solutions for their users — Fedora isn’t just the toolkit. Many of
our contributors are here to collaborate to create solutions for specific
user problems" , Diversity events will help us bring out different kind of
requirements for different user base. For example disabled people user base
and by identifying such requirements we will be able to serve them more
easily. Here is the LGBTQA event report link, which can be referred to
understand it more clearly -https://communityblog.fedoraproject.org/event-report-may-17-lgbtqa-awareness-day/

Target tasks before flock
================
These are the tasks to be done before flock for this workshop-
1. Create wiki pages and pagure tickets of all the events. - We already have
for few.
2. Add the existing events to Diversity Team Fedocal.
3. Create Formats and flow of the events.

Collection of three short Modularity talks:

1/ Modularity Today & in the future! — Langdon White, Adam Samalik
We have now released the preview of the Modular Distro. We plan to release the Server Edition fully modular. Users can elect to take advantage of these components or use the system(s) in a more traditional way. So.. what's next?

Well, as many of you know, we still have a very large OS-layer and cannot be as independent in our application lifecycles as we would like. What can we do now?

During this talk we will propose various mechanisms for increasing the lifecycle independence including new packaging, packaging automation, considering dynamic loading of libraries using new mechanisms. We will also show how containers can be better leveraged as core parts of a user's system allowing for the independence of those components from the OS and other applications.

The future is exciting and allows for significant innovation. Let's work together to define it.


2/ The Module Build Service — Ralph Bean
The Module Build Service (MBS) is live! We presented the first
prototype of the MBS as part of the Modularity presentations at last
year’s Flock in Krakow. It has been a year now. Time to review! We’ll
discuss:

- The history of thinking on “how to build modules”. What has changed in the last year?
- A review of MBS internals. How does it work today? You can help make it better!
- What missing features we would like to see implemented in the coming year.

Come for a walk down memory lane and a glimpse at the future. Cheers!


3/ Packaging Modularity — Adam Samalik
Packaging in Modularity is different. There is not a single huge space where all the people work anymore. A package doesn't need to come just in a single version. All packages doesn't need to be supported on the same level. Your personal package does not need to break other people's work just because they started to using it...
I will compare packaging of the classic distribution with modularity. Will show you how modularity packaging looks now - what's good, what's bad, what's crazy

Currently we are shipping Workstation, Server, and Atomic. All of them in different versions like F27, F28, F29, etc. How is this going to look like with Modularity? Are we going to stay with versions? Are we going to have a different versions for different modules? Are we going to ship editions as we do today, or are we going to ship the platform + the modules independently? And how is packaging going to change? Please come and discuss the future of Modularity!

If you are planning to attend this workshop, please follow these instructions to download cached content needed for the workshop.

This is a workshop. It is targeted at Fedora package maintainers, Fedora developers and Fedora release engineers.

Outcome:
* audience gets hands-on experience with creating modules
* audience knows how to build a module in production infrastructure and can try it out
* audience is aware of best practices for creating modules
* audience is familiar with whole build pipeline

Agenda:
* short introduction to modularity
* demonstrate a real module, which is already present in infrastructure
* go over though all the steps which take place in the pipeline (dist-git, mbs, koji, testing, module-aware dnf)
* initiate a workshop where audience is meant to create a module of their favorite package/stack
* in this step, presenter should be showcasing module creation live, while other modularity members assist people with module creation
* during this part, best-practices for module creation should be constantly discussed
* if time allows, create at least one test which would prove the module works correctly
* modularity team should gather feedback from audience and incorporate it into documentation
* in the end of workshop, review modules created by audience — ideally get them into production infrastructure

Modularity-testing-framework has been designed for testing artifacts like modules, rpm base repos, containers and the others which comes from Modularity team. It helps you to write tests as simply as possible and independent of module type.
Let's write our own tests for modules or containers
Outcome:
* audience knows how to create a test for modules/containers
* audience knows how to test modules/containers
* audience is aware of best practices for creating modules/containers
Description:
* short intro to modularity and modularity-testing-framework
* demonstrate a real module/container
* test it
* ask audience to create a test of their favorite package
* create a new test live

In this session all participants should bring a copy of a book that they really like and consider to be useful for FLOSS/Fedora contributors. It could be anything from technical references, books about personal growth, project management, community building or inspirational autobiographies. At the beginning everyone should present their book and tell why they think it is great. Afterwards there is time to talk about the books and take a look into the copies that others brought. By sharing their experience and recommendations for good books, Fedora contributors can learn how to improve and share their ideas about improving their contributions on both a social and technical level.