Category: Events (page 10 of 25)

All articles in this category are related to any all events in Fedora, whether they be in-person or remote (e.g. Fedora Activity Days, Flock, FUDCons). https://fedoraproject.org/wiki/Events

Modularity Hackfest, March 2019

March 8, 2019 / Stephen Gallagher / Comments Off

Some time ago, the Modularity team in Fedora attempted to organize a proper hackfest on Modularity. The hackfest was intended to gather together members of the Fedora community (both internal and external to Red Hat) in Ireland and work through some of the bigger UX and packaging concerns around Fedora Modularity. Unfortunately, the planning and funding for the hackfest fell through. However, it turned out that we were able to pull together a less-ambitious hackfest in the Red Hat Boston office over Monday and Tuesday (at effectively no notice). The attendance was a bit limited, but we were able to get several people together along with several more through video-conferencing technology.

Among the attendees from Red Hat were Petr Šabata, Langdon White, Adam Šamalík, Mohan Boddu and Matthew Miller. From outside of Red Hat, we were joined by Neal Gompa and Igor Gnatenko.

Much of this two-day hackfest was spent identifying and scoping the most urgent problems that we need to solve. We opened the session by inviting Neal Gompa to report on his experiences with attempting to consume and build modules for the projects he works on in his day-job. In particular, his internal toolchain uses the Open Build Service (OBS) to build his tools on multiple operating systems. At present, OBS does not handle repositories with modular content appropriately. OBS relies directly on libsolvext for working with repodata which does not currently handle the module metadata. As a result, the Fedora Modular and Red Hat Enterprise Linux 8 Beta AppStream repositories look like a collection of conflicting data.

We spent quite a lot of time in discussion on this topic and eventually broke it down into two specific problems to solve. First, we need to work with libsolvext upstream to add support for reading the modulemd YAML format. Second, we need to then convert the data read by this format into “solvables” that can be processed by libsolv. This will enable OBS to process modules in an appropriate manner (and may eventually be able to replace the implementation done by libdnf). The first issue is currently blocked on libsolv upstream’s unwillingness to include the libyaml parser, preferring to insist that modulemd be provided instead as XML. However, Igor (a member of libsolv upstream himself) has become sufficiently convinced that such a switch won’t happen and is going to approach the rest of upstream to reconsider their stance.

The third primary issue we identified was that there exists some content that is used when building Fedora and RHEL 8 Beta modules that are not published outside of the build-system, resulting in those modules being impossible to reproduce externally. In Fedora we have modules (called “buildroot-only” modules) that are not shipped in any public repository. As it relates to reproducibility of the distro, we will probably need to publish this content somewhere. We discussed with Mohan (the Fedora release engineering lead) that we may want to provide a new repository for this content that we will not mirror widely (and probably produce without deltarpms, etc so as not to unnecessarily slow the compose process).

The last big issue we discussed was the difficulty currently faced by users who want to build their own modules locally. To define the term “locally”, we mean that once the necessary dependencies are cached onto the local system, it should be possible to complete builds and rebuilds without any internet access. Today, the MBS has limited local build functionality out of the box for building Fedora modules. However, it is not truly local, as the build process will reach out to Fedora’s infrastructure including both Koji and PDC at some points. We agreed that the MBS needs to be updated to be able to either cache all content locally or be directed at a specific site-mirror of the repositories to be able to perform builds without access to the Fedora Infrastructure. In the case of RHEL 8 modules, this becomes even more urgent as anyone outside the Red Hat firewall will not have access to the Red Hat MBS and Koji instances.

Beyond the problems with network access, we also looked into what people will need to be able to do in order to compose and release their third-party modules in their own repositories, either internal to their organization or publicly as a non-official Fedora or RHEL repository. Today, there are painfully-difficult ways to accomplish this with the createrepo_c family of tools, but those present at the hackfest agreed that we need to enhance this experience by making module metadata a first class citizen in those tools. To that end, I opened several issues against the createrepo_c project:

Issue 131: Make module metadata a first-class citizen in mergerepo. This is necessary to ensure that tools that want to compose modular content will be able to update their final repos with the content produced by a local MBS build. In other words, it must be possible to take the module-specific repo created by an MBS local build and add it to a combined repository without a log of manual steps to set the module metadata correctly.
Issue 132: Add package checksums to the module metadata when creating a repository. This is needed for libsolvext, as it uses the checksums as the lookup key for each package.
Issue 133: Similar to how it handles packages, when running createrepo_c or mergerepo_c, it needs to be possible to exclude a subset of modules from the resulting repository.

As we were discussing these createrepo issues, we also identified several gaps in the libmodulemd API that will need addressing to support them.

Issue 208: In order to simplify things for libsolvext and createrepo_c, libmodulemd needs to be able to decompress modules.yaml.gz or modules.yaml.bz2 streams.
Issue 209: In support of the createrepo issue 133 above, we need to add a routine to make it simple to exclude an entire module (defaults object and all) from a ModuleIndex object.
Issue 212: We discovered in our discussions a shortcoming in the libmodulemd 2.x API. It made an incorrect assumption that separate CPU architectures would always be contained in separate repositories. Neal noted that there are some prominent repositories in the wild that converge multiple arches into a single repository. We will need to evaluate whether we can fix this without breaking API.

The hackfest also discussed a number of issues around upgrades from one release to the next, including the current issues plaguing efforts around the Fedora 30 Beta. We brought in Adam Williamson of the Fedora QA team for this part of the discussion. In this case, we reached a clear agreement that the currently-proposed workaround on the Fedora Devel mailing list (of requiring users to pass a special --setopt argument to the upgrade command) is not an acceptable solution for Fedora 30 Beta. We will ask that the DNF team find a way such that the existing expected commands dnf --releasever=$NEXTVERSION system-upgrade download must work without additional arguments.

Open Questions:

We had some discussions throughout the course of the hackfest that didn’t reach a clear consensus. The most contentious was around what to do about empty profile data. There are several uncommon cases that need to have clear UX decisions made around them.

A module does not have one or more of its profiles specified to be the default.

The module creator has not provided a defaults object into the YAML (in Fedora, this is done by requesting it be added by release engineering or submitting a pull request to the fedora-module-defaults repository). This may be intentional or unintentional. Fedora QA has asked us if they should be treating the lack of a defaults reference for the profile as a failure, since this is something that could be detected during post-compose testing and reported. My personal opinion on this case is that for modules in Fedora itself, we should indeed treat this as a bug and require that all modules have a defaults object that properly references a set of default profiles for any stream included in that compose.

The open question here is what the DNF experience should be if dnf module install modulename:modulestream is called. The current behavior is that DNF treats this as equivalent to calling dnf module enable modulename:modulestream (it makes the contents of this module explicitly available, but installs nothing at that time. Feedback from users of the RHEL 8 Beta have indicated that this is an unexpected behavior of the install verb. They’d prefer to see DNF report an error if install is called and results in no packages being installed. In part, this is because it would be silently hiding the possibility that the defaults are missing.

A module has explicitly set one or more of its streams to have no default profiles

This is a similar case to the above, except that a conscious choice was made by the module maintainer to say that this module has no reasonable default packages that could be selected. (For example, it could be a collection of popular libraries that extend a particular programming language, but there’s no obvious subset of them that makes sense to install. It may exist and have streams solely because it needs to be kept in sync with the interpreter version.)

The open question is the same as the previous one: how should dnf module install handle this case? In this particular example, it might be more acceptable that it follows the enable fallback, since the maintainer selected the lack of a profile explicitly. However, having context-sensitive differences can be difficult for people to process.

A module has a profile that contains zero RPMs

In this case, a profile definition has been made in the module metadata and it explicitly contains zero RPMs within it. Such an example might be for compatibility: the module previously provided a profile with that name that contained content, but it is no longer doing so. Retaining the name may have been done to allow existing scripts to avoid breaking. If we have a profile that contains zero packages, should it be an error if we attempt to install it? If not, what should the UX look like?

Open Power Summit 2018 event report

February 4, 2019 / jcajka / Comments Off

With some rather unfortunate delays is my report from last year’s Open Power Summit. Let’s dive in it, without further delay.

It took place between 3th and 4th October 2018 in Amsterdam, Netherlands. It is event organized by the Open Power Foundation, steward of the Open Power CPU ISA. It is open and builds on top of the heritage of the past Power architectures, enabling any vendor or individual to dive in to the technical deeps of it or even implement it on their own.

At the venue there have been booths of different foundation members and affiliated organizations. Like Raptor engineering with their Talos II and Blackbird platforms on showcase, Mellanox with accelerators cards, Yadro with big-data memory(RAM) dense servers or OpenCAPI consortium with bunch of accelerators from various manufacturers that are leveraging the OpenCAPI standard, just to note few. To add on the OpenCAPI it is open offspring of the CAPI that has been introduced by IBM with their Power8 architecture.

Fedora Council December 2018 Hackfest Report

January 3, 2019 / Matthew Miller / Comments Off

In December, the Fedora Council met in Minneapolis, Minnesota for several days of meetings. With the holidays now behind us, here’s our summary of what happened.

Strategic direction update

The most important part of the meeting was our update to Fedora’s strategic direction. You may have read the Community Blog post about this already. While the wording — or at least the fact that we’ve written it down — may be new, the ideas aren’t. This document represents the next step from the efforts that began with Fedora.next back in 2013. Our goal is to allow members of the Fedora community to build solutions that focus on the specific requirements of their target users. This means, among other things, a more decomposed and self-service build process.

The earlier post generated a lot of discussion and feedback. I’m planning a series of Community Blog articles summarizing and responding to that feedback — stay tuned!

Objective updates

We also heard from three of the four current Objective leads. (Our Internet of Things lead, Peter Robinson couldn’t make the meeting, unfortunately.) The CI/CI Objective is wrapping up and Dominik Perpeet will be publishing a summary soon. The Modularity Objective is also ending its current phase. Modules for Everyone was a key feature of Fedora 29, and the Modularity team is continuing to improve the technical implementation as well as make it more approachable for community contributors. Both Objective leads will be proposing next steps to the Council in early 2019.

The Lifecycle Objective is just getting started. It has two goals: make the release process scale and allow & encourage more community ownership for deliverables. This ties in tightly to the strategy update — this work is required to get us to where we want to be. Paul Frields is working to gauge what’s needed to implement this now, including the proposed long cycle for Fedora 31 (discussed on the devel mailing list). The Council in general would prefer to keep to the regular six-month cycle.

Mindshare

The Mindshare team previously adopted a policy of spending up to $100 for release parties with minimal approval required. This has been successful, and the Council would like Mindshare to build on this with further investment. We agreed that Mindshare should adopt a policy of allowing up to $150 for activities that promote the use of Fedora solutions in communities. This could include release parties, web hosting, or other relevant activities. We want to encourage experimentation, so we’re not requiring the activities to be successful to get reimbursed — they just need to be successful to get future funding. The Council’s goal is to have 100 of these proposals funded in FY2020 (which starts in March of 2019). In order to encourage funding these proposals throughout the year, unallocated funds from this budget will be pulled into the Council budget at the end of each fiscal quarter. Look for guidance from Mindshare on how to make these requests soon.

Communication

We’ve started experimenting with using Discourse as the asynchronous communication tool for some teams. For synchronous communication, some teams are using Telegram in addition to — or instead of — IRC. Each platform has strengths and weaknesses. After discussion, the Council came to the conclusion that communication fragmentation is unavoidable. In a project as big as Fedora, people work in different ways and have different preferences. We leave it to each team to decide what communication methods work best for their team.

To help connect everyone together despite this, we have requested a central project management service from the Infrastructure team — probably Taiga, although we’re asking the team to also look at GitLab for this purpose. We’ll have a dedicated instance, likely hosted, and we ask each team to have a minimum presence on that tool, whether they use it otherwise or not. The presence should, at a minimum, indicate the team’s communication methods for synchronous and asynchronous communication and where project information may be found if not in the shared tool. That way, there will be an automatically-curated list of active teams. (See https://tree.taiga.io/discover for an idea of what this would look like — imagine each project there is a Fedora team.)

Infrastructure

The success of our strategy depends on improvements to our infrastructure. The Infrastructure team has limited resources, so we need to ensure they’re able to work on areas that add the most value to the project. This means a shift away from running all layers of the stack and focusing more on application management. The goal is to have the Infra team administering applications, not low-level infrastructure. (Even if that makes the team name confusing — sorry!) We want agility in our applications and deployment. We want drive-by contributors to be able to realistically contribute to the infrastructure team.

We also talked about GitHub. Ideally, we want everything to be on open source services (e.g. Taiga, Pagure, or GitLab). But, as a pragmatic matter, we recognize that GitHub has a huge network effect — there are millions of users and developers there, and millions of open source and free software projects hosted there, including software that’s fundamental to the Fedora operating system. We’d like better integration and syncing with tools like Pagure to give access to that network effect on all-free software, but we also know that there isn’t a lot of developer time to make and maintain those kind of features. Therefore, we’re willing to accept people in Fedora hosting their subprojects on GitHub. We’ve got to focus on what we do that’s unique (and only do things which are unique when we have a special need to meet our project goals). Git hosting is not one of those things.

General Council business

The Council wants to make it clear that community input is welcome on Council matters. Members of the Fedora community may provide non-binding votes on Council tickets and participate in meetings. Speaking of meetings, we’re replacing the Subproject report meetings with regular updates from the FESCo, Mindshare, and Diversity & Inclusion representatives. This should help provide better visibility into those organizations for the Council and the community at large.

We will also move all Council policies out of the wiki to docs.fedoraproject.org. The Council will use the wiki only as a scratch space for works in progress. Durable documentation will live on the docs site. We encourage other teams to consider doing the same.

Meeting Minutes

We didn’t actually conduct the meeting in IRC, but we took minutes in the same way. Here’s our detailed record.

#startmeeting Fedora Council Hackfest 2018

#chair mattdm bcotton tyll contyk dperpeet langdon dgilmore bex jonatoni sumantro stickster

#topic Mission overview + Strategic framework

#info Community Members are encouraged to contribute to the decision process with non-binding votes

#link https://qz.com/work/1468580/the-four-layers-of-communication-in-a-functional-team/

#info mattdm shows his favorite graph

#topic Fedora Project Strategy: “How do we make our mission real?”

#action Dominik will speak more loudly

#agreed Council will replace subproject report meetings with updates from FESCo, Mindshare, and D&I rep

#agreed Council adopts the strategy proposal (+9, 0, -0)

#action mattdm to post the strategy proposal to commblog

#agreed Council will make a final vote on the strategy proposal on 9 January 2019 (+8,0,0)

#topic Moving Council Policies to Docs

#agreed Council will move all Council policies and other durable Council documents from the Wiki to docs.fedoraproject.org and remove old wiki pages. (8,0,-0)

#info policies should be kept in a repo separate from other documents for ease of watching

#topic Objective Update: CI/CD

#action

dperpeet to write up final objective report for publication on Community Blog by January 1

#action dperpeet to propose a new Objective for future CI/CD work

#info the new Objective should include working with other stakeholder groups including IoT and SilverBlue

#topic Objective Update: Modularity

#action langdon to propose a new Objective for future Modularity work

#topic Objective Update: Lifecycle

#topic $150 release parties

#agreed Mindshare should move the easy process to $150 and encourage more non-RP uses (+9,0,-0)

#agreed: Mindshare should start providing $150 base support for solutions to help them grow (+9,0,-0)

#agreed: Mindshare should start attracting larger requests and develop a process. These requests are judged using Council provided Fedora Project strategy as guidance. (+9,0,-0)

#agreed: Mindshare should target at least 100 $150 events in FY20 (+9,0,-0)

#agreed Unspent budget allocated to the $150 event program will be pulled into the Council budget at the end of each fiscal quarter beginning with FY20 (+10,0,-0)

#topic Localization

#action bex to begin a conversation in the translation community about a platform that meets the needs of the translation workflow

#topic Logo

#info Adam Miller will not get a tattoo with our current logo because people will ask him why he has a Facebook tattoo

#info The design team is working on getting a proposal to the community to vote soon so we can select the new one by January 31 in final form for production

#topic Infrastructure

#agreed The Council supports greater efficiency in the infrastructure to allow more to be done, even when this means that we move away from self-hosted or self-maintained infrastructure. (+9,0,-0)

#agreed The Fedora Project wants to advance free and open source software and as a pragmatic matter we recognize that some infrastructure needs may be best served by using closed source or non-free tools today. Therefore the Council is willing to accept closed source or non-free tools in Fedora’s infrastructure where free and open source tools are not viable or not available. (+9,0,-0)

#action contyk, FESCo to work with Infra to examine current applications and determine: 1. which applications can be moved out of the datacenter immediately or in the short term, 2. Which applications have industry-standard open source or proprietary alternatives that we could move to.

#topic Communication

#agreed Fedora will offer a central place for teams and SIGs to be discoverable, do project management, etc. Having a landing page will be a requirement for all teams and SIGs in Fedora. (+10, 0, -0)

#agreed The Council will ask the Infrastructure team to evaluate providing the central place as Taiga versus Gitlab based on requirements provided by Council. (+10, 0, -0)

#action mattdm to write requirements doc for these two things above.

#agreed The Fedora Council embraces fragmentation in our communication platforms — this is a reality we can’t fight. The Central Place will provide a way for anyone to find the communication tools used by any group. (+10, 0, -0)

#topic Ticket #198

#agreed Document proposed in ticket #198 is accepted for delivery to Legal for drafting updates to the Trademark policy. (+10, 0, -0)

#topic Code of Conduct enforcement

#agreed The FCAIC is empowered to take action on Code of Conduct reports with an additional +1 from another core Council member or the Diversity & Inclusion Advisor and report back to Council. (+10, 0, -0)

#topic Ask Fedora and getting help

#agreed Council authorizes the hosting of a separate Discourse instance to replace ask.fedoraproject.org to be funded out of Fedora community budget. (+9, 0, 0)

#endmeeting

Everybody want Fedora swag

Linux Day 2018 – Italy

November 15, 2018 / alciregi / Comments Off

Every year, on the last Saturday of October, in Italy there is a national event called “Linux Day”. This year was the 18th edition and it was held on October 27.

The event is promoted by the Italian Linux Society, and it is independently organized in many cities all around the country by groups of volunteers, LUGs and various associations. Even if it is highly fragmented (many little events in many cities), it is probably the biggest Italian event related to Linux and FLOSS, that is directly organized by people involved in the communities and by ordinary users.

The aim of such event is to to promote Linux and FLOSS in general: in each city there are many talks, presentations and installation parties. The target audience is not limited to computer enthusiasts, hackers or IT professionals, but newbies, students and curious citizens are welcome as well.

FAW 2018 Day 5: “Encouraging crazy ideas”

November 9, 2018 / Justin W. Flory / Comments Off

Today is Day 5 of Fedora Appreciation Week and the final day of published Contributor Stories. To help celebrate the Fedora Project, our fifteen-year anniversary, and the community of people that make Fedora what it is, the Community Operations team collected Contributor Stories from the community to feature here every day of Appreciation Week.

Have someone you want to thank? Do you want to share your appreciation with Fedora? See how you can celebrate 15 years of Fedora and participate in Fedora Appreciation Week over on the Fedora Magazine.

Some new stories came in during this week. Today, there are five stories to read from four people: Bhavin (bhavin192), Giannis Konstantinidis (giannisk), Eduard Lucena (x3mboy) and Dhanesh Sabane (dhanesh95).

FAW 2018 Day 4: “You know you can do it”

November 8, 2018 / Justin W. Flory / Comments Off

Today is Day 4 of Fedora Appreciation Week. To help celebrate the Fedora Project, our fifteen-year anniversary, and the community of people that make Fedora what it is, the Community Operations team collected Contributor Stories from the community to feature here every day of Appreciation Week.

Today’s Contributor Stories come from three people: Chhavi Shrivastava (chhavi), Eduard Lucena (x3mboy), and Alberto Rodríguez Sánchez (bt0 / bt0dotninja).

Fedora Women’s Day 2018 – Trieste

November 8, 2018 / hysdue / Comments Off

On September 29, the hackerspace Mittelab of Trieste had the honor to host the first edition of the Fedora Women’s Day event. Organized by the Fedora Diversity and Inclusion team, the event aims to break down gender walls to allow all women passionate about IT and technology in general to approach the Fedora operating system. During the day there were a series of conferences whose purpose was to show this distribution and define the main features of Linux.

FAW 2018 Day 3: “Becoming part of Fedora family because of her!”

November 7, 2018 / Justin W. Flory / Comments Off

Today is Day 3 of Fedora Appreciation Week. To help celebrate the Fedora Project, our fifteen-year anniversary, and the community of people that make Fedora what it is, the Community Operations team collected Contributor Stories from the community to feature here every day of Appreciation Week.

Today’s Contributor Stories come from three people: Alberto Rodríguez Sánchez (bt0 / bt0dotninja), Chhavi Shrivastava (chhavi), and Alessio (alciregi).

FAW 2018 Day 2: “Change the world through Open Source. He said.”

November 6, 2018 / Justin W. Flory / Comments Off

Today is Day 2 of Fedora Appreciation Week. To help celebrate the Fedora Project, our fifteen-year anniversary, and the community of people that make Fedora what it is, the Community Operations team collected Contributor Stories from the community to feature here every day of Appreciation Week.

Today’s Contributor Stories come from three people: Chhavi Shrivastava (chhavi), Solanch (solanch69), and Justin W. Flory (jflory7 / jwf).

FAW 2018 Day 1: “Community makes the difference”

November 5, 2018 / Justin W. Flory / Comments Off

Today marks the inaugural kick-off of Fedora Appreciation Week. To help celebrate the Fedora Project, our fifteen-year anniversary, and the community of people that make Fedora what it is, the Community Operations team collected Contributor Stories from the community to feature here every day of Appreciation Week.

Today’s Contributor Stories come from three people: Bee Padalkar (bee2502), Eduard Lucena (x3mboy), and Dyuti (recursedd).