Tag: Modularity (page 1 of 2)

Posts related to the Fedora Council’s Modularity Objective.

What I have found interesting in Fedora during the week 45 of 2017

My highlights from the past week:

Fedora 27 Modular Server Beta & Fedora 27 Final are considered as Gold

On Thursday, November 9th, 2017 we have finally concluded the Fedora 27 Final compose as well as the Fedora 27 Modular Server Beta compose are ready to be released. The release date for both composes is November 14th at 14:00UTC. For more information you can check the meeting minutes from the Go/No-Go meeting.

Name of the Fedora Server release

During the past time there was a discussion what name we should be using for the Modular release of the Fedora Server edition. On the Server SIG meeting the last week a decision has been made to use Fedora Modular Server. The main reason why this name has been chosen is to avoid end-user confusion.

Fedora 27 Modular Server release validation

The Beta release of the Fedora 27 Modular Server was made under considerable pressure. To be sure we do not step aside from our quality standard, our QA team (namely Adam Williamson) has put together test matrices for the Modular Server and has aligned the Modular Server testing with the way we do validation of the standard release.

Changes Policy & Fedora Release Life Cycle

No More Alphas Change has implemented some changes in the way we plan and deliver Fedora Releases. During the Fedora 27 release we were improvising a bit to find the balance between the changes we needed to do and the overall stability of the release cycle. Finally, as the release is almost shipped, we have merged all the changes in Changes Policy & Fedora Release Life Cycle together with some tweaks and proposed a new versions of these documents. The draft of the Changes Policy as well as the draft of the Fedora Release Life Cycle  is now available for review. Once the review is done, I will bring these drafted documents to FESCo for the final approval. If you are interested in this, please contribute to the discussion on the devel@ mailing list.

Autumn elections

The preparation phase of the Autumn 2017 Elections is still in the progress. This Election cycle is following the schedule approved by Fedora Council and we are now collecting questions in our Election questionnaire. Anyone who would like to ask our candidates to FESCo, Council, Mindshare any question, can contribute into the Questionnaire. The collection of questions ends in one week on November 20th, 2017 at 23:59:59UTC.

What I have found interesting in Fedora during the week 42 of 2017

After a week I would like to share some activities in Fedora happened since my last post:

Fedora 27 Server Beta is No-Go

On Thursday, 2017-Oct-19, we had a second round of the Go/No-Go meeting for the delayed F27 Beta release of the Server (modular) edition.  Result of the meeting is No-Go due to missing Release Candidate compose. We are going to run third round of the Go/No-Go meeting on Thursday, 2017-Oct-26 at 17:00 UTC together with the Go/No-Go meeting for F27 Final release.

Fedora 27 Final Freeze

Since Tuesday, October 17th we are in a Freeze period for F27 Final. It means the F27 Final release is pretty close and we are going to run Go/No-Go meeting on this Thursday, October 26th as well as F27 Final Readiness meeting.

Rawhide renamed to Bikeshed for the Modular Server

This is not a news from the last week, however I have realized not many people know about this.  At the beginning of October has been “rawhide” renamed to “bikeshed” for the Fedora Modular server. So, nowadays you can find the latest modular builds on Koji under the latest-Fedora-Modular-Bikeshed directory.

New election app

Thanks to Ryan Lerch, Justin Flory and Pingou we now have installed a new version of the Voting Application in the staging environment. Hopefully the new version will be available for the upcoming elections once F27 is made GA.

And of course, the list above is not exhaustive and there is much more going on in Fedora community. The list above just summarizing some tasks which has drawn my attention.

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

Fedora speakers at FOSDEM 2017

Excited for FOSDEM 2017? FOSDEM, or the Free and Open Source Software Developers’ European Meeting, is held every year in late January or early February. This year, FOSDEM is taking place on February 4th and 5th. At this year’s conference, an estimated 8,000 or more attendees are expected. As one of the largest open source conferences in Europe, there are many Fedora Project developers and representatives attending the event. In addition to our community stand, you will find 24 speakers from the community giving talks over the weekend. This post gives a quick way for you to find out who is speaking and where to find them in FOSDEM!

Continue reading

Fedora Docker Layered image build service now available

Announcing: Fedora Docker Layered Image Build Service is GO!

It is with great pleasure that the Fedora Project Announces the availability of the Fedora Docker Layered Image Build Service to the Fedora Contributor Community!

With this announcement we open the availability of the Docker Layered Image Build Service for the Docker Layered Images. The Fedora Cloud WG has been the primary maintainers of this project on GitHub. But now the service is available in dist-git as official components of Fedora. From there we will extend an invitation to all Fedora Contributors to maintain Docker Layered Image Containers for official release by the Fedora Project. Currently this effort is to enable the Fedora Cloud/Atomic Working Group goals of targeting Fedora Atomic Host as a primary deliverable to power the future of Cloud. This is also to enable the Fedora Modularity work be delivered as Containers in the future as Fedora becomes fundamentally more modular in nature.

Continue reading

Base Runtime and the Generational Core

A Quick Primer on Modularity

lego_chicago_city_view_2001Modularity (formerly, Modularization) is an ongoing initiative in Fedora to resolve the issue of divergent, occasionally conflicting lifecycles of different components. A module provides functionality (such as a web server) and includes well-integrated and well-tested components (such as Apache httpd and the libraries on which it depends). It can be deployed into production in various ways: as “classic” RPM packages or a container image, and is updated as a whole. Different modules can emphasize new features, stability, security, etc. differently.

Modules differ from traditional packaging in certain important ways. Perhaps most importantly, they allow us to separate internal implementation details from the exposed interfaces of the module. Historically in Fedora, if a packager wanted to deliver a new web application, that would also often mean that they needed to package and carry the framework or other libraries used by that application. This tended to be a double-edged sword: on the one hand, those libraries were now available for anyone to pick up and use in Fedora. However, in many cases, this meant that the primary maintainer of that package might actually have no specific knowledge or understanding of it except that its lack would mean their application didn’t work. This can be a problem if a person is carrying around a library for the use of a single helper function and don’t want to be responsible for issues in the rest of the library.

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

What are Personas and why should you care?

The Modularity working group is looking to flesh out a set of personas to help focus the work being done by the team. Personas are fictional characters created to represent the different user types that might interact with a “product” in different ways. They are not market segments but should be thought of as user archetypes.

Personas can be useful in considering the goals, desires, and limitations of users to guide decisions about a product.  They should be based on user research and can include all types of information about that particular person.  Our personas include information related to behavior patterns, goals, skills, pain points, attitudes and daily activities.  If you want to learn more about personas and their use, I recommend your start here.

Benefits of personas

Some benefits a team can see with personas include:

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

Olderposts

Copyright © 2017 Fedora Community Blog

Theme by Anders NorenUp ↑