Search results: "modularity" (page 1 of 5)

Fedora 28 Add-on Modularity Test Day 2018-04-10

Tuesday, 2018-04-10 is the Fedora 28 Add-on Modularity Test Day! As part of the change, we’ll be testing the new add-on modules on the latest Fedora Server.
We need your help to test if everything runs smoothly!

Why Modularity Test Day?

Many of you would have read the amazing article which came out months ago!
Featuring one of major change[1] of Fedora 28 Server we would test to make sure that all the functionalities are performing as they should. Continue reading

Modularity is Dead, Long Live Modularity!

Summary

Fedora’s Modularity initiative aims to make it easy for packagers to create alternative versions of software and for users to consume those streams simply. We’ve been working on this for several years, resulting in the “Boltron” prototype this summer and the recent Fedora Modular Server beta. Feedback shows that these test releases didn’t meet the goal, and we’re incorporating that in a modified design which we think will. We plan to demo the new approach by DevConf.cz and FOSDEM.

Continue reading

Documentation and Modularity at Flock 2017

If I had to choose one buzzword for Flock 2017 at Cape Cod, it would be ‘modularity’. Modules, module building, module testing, and module explaining seemed to be all over the place. I attended to give a workshop (with Aneta ŠP) about a proposed way to inject new life into the Fedora Documentation Project. Continue reading

Flock interviews: User Feedback on Modularity

As you probably know, there is annual convention called Flock. This year’s is happening in Cape Cod, Hyannis, MA and will begin the morning of Tuesday, August 29. Sessions will continue each day until midday on Friday, September 1.

I have asked all of the session leaders from Flock some questions.

And now you are about to read one of the responses.

User Feedback on Modularity by Mary Clarke

Briefly describe your session:

I will actually have 6, 1-hour sessions during the course of Flock. They will be in the hour before the lunch break and the  hour after the lunch break on Tuesday, Wednesday, and Thursday. The reason we are doing this is that my sessions are not typical talks, in fact, they are not talks at all. You could describe them as focus groups intended to obtain end-user feedback. These sessions are intended to be highly interactive where we will demo functionality and ask for attendees to respond with their thoughts. I have provided more information through my answers below.

Continue reading

What does Factory 2.0 mean for Modularity?

This blog now has a drop-down category called Modularity. But, many arteries of Modularity lead into a project called Factory 2.0. These two are, in fact, pretty much inseparable. In this post, we’ll talk about the 5 problems that need to be solved before Modularity can really live.

Continue reading

Modularity Infrastructure Design

Co-authored by Courtney Pacheco and Ralph Bean

Note: This article is a follow-up to Introduction to Modularity.


Introduction

The purpose of our Modularity initiative is to support the building, maintaining, and shipping of modular things. So, in order to ensure these three requirements are met, we need to design a framework for building and composing the distribution.

In terms of the framework, in general, we are concerned about the possibility of creating an exponential number of component combinations with independent lifecycles. That is, when the number of component combinations becomes too large, we will not be able to manage them. So that we don’t accidentally make our lives worse, we must limit the number of supported modules with a policy and provide infrastructure automation to reduce the amount of manual work required.
Continue reading

Introduction to Modularity

What is Modularity?

Modularity is an exciting, new initiative aimed at resolving the issue of diverging (and occasionally conflicting) lifecycles of different “components” within Fedora. A great example of a diverging and conflicting lifecycle is the Ruby on Rails (RoR) lifecycle, whereby Fedora stipulates that itself can only have one version of RoR at any point in time – but that doesn’t mean Fedora’s version of RoR won’t conflict with another version of RoR used in an application. Therefore, we want to avoid having “components”, like RoR, conflict with other existing components within Fedora.

Although RoR can be thought of as a component, the definition of “component” is actually a work-in-progress. In other words, another example of a component might be a “LAMP module”, where module is defined as a well-integrated and well-tested set of smaller components that provide functionality. The LAMP module would contain the necessary smaller components required to build and deploy a dynamic, high-performance Apache web server that utilizes MariaDB and PHP. Such a module would be completely independent of all other modules.

Continue reading

Modularity Use Case: Application Independence

A modularity use case in Fedora is much like working with legos.We will be writing a series of blog posts regarding the project to help the Modularity effort move forward. Some of the posts will be about “Why?” and some will be about “How?” As the first post in the series, this article is about “Why?

The Rings Proposal and the Modularity Objective are both about big ideas and a long-term vision. And it should be all those things. Grand visions are how Fedora is what it is today.

Continue reading

Mindshare Monthly Report – FAD and First Actions

Establishing the Committee

The Mindshare Committee is officially established.

The Fedora Mindshare Committee represents the outreach leadership in Fedora. Mindshare aims to help outreach teams to work together better by providing them with a way to unify around Fedora’s messaging and work together to achieve goals.

We had a FAD where we we met to discuss how the committee is going to work and to discuss the initial issues we had on our hands. We did a little recap of good things and challenges:

Good:

  1. Events: Ambassadors organizing minor events and presenting at main events
  2. Budget process: Mostly working in part to a dedicated role in Fedora
  3. Design & Web: Two teams collaborating together and offering a good user experience and a model for collaboration
  4. Marketing: Fedora Magazine and generating talking points
  5. Docs: We have Docs, but at Flock when this was originally presented, the team was small; Docs FAD was last week and may impact this

Challenges:

  1. Communication: Missing effective communication between teams
  2. Best practices: Not shared between teams, some teams have efficient processes that could be used by others
  3. Reporting: The events we attend are not informing the project and helping us set direction
  4. Marketing: Disconnected from other teams and its messages need to drive outreach teams again
  5. Local communities: Strong interest from local communities but support is not in place to help engage and include them in the project

Having this list in our hands, we started a discussion, about the topics, our challenges and taking advantage of our good points. The first thing we did was create a list of objectives:

  1. Improving communication between teams
  2. Better collaboration and sharing of best practices between teams
  3. Supporting management of budget for impact
  4. More informed event planning with inputs from several groups

Continue reading

Bodhi: 2017 Year in Review

2017 was a busy year for the Bodhi project. This post explains a bit about what Bodhi does, highlights, and goals for 2018.

Wait, what is Bodhi?

Bodhi is designed to democratize the package update testing and release process for RPM-based Linux distributions. It provides an interface for developers to propose updates to a distribution, and an interface for testers to leave feedback about updates through a +1/-1 karma system.

Continue reading

Olderposts

Copyright © 2018 Fedora Community Blog

Theme by Anders NorenUp ↑