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!
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
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.
My highlights from the past week:
After a week I would like to share some activities in Fedora happened since my last post:
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.
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.
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.
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.
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
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!
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.
Modularity (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.
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.
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.
Some benefits a team can see with personas include:
Copyright © 2018 Fedora Community Blog
Theme by Anders Noren — Up ↑
Recent Comments