Development & Packaging Archives – Page 12 of 15

Category: Development & Packaging (page 12 of 15)

All articles in this category are related to engineering teams in the Fedora Project, in particular teams working on packaging and release engineering. https://fedoraproject.org/wiki/Development

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:

FOSS Wave: Women in Technology (Part 2)

September 5, 2016 / a2batic / 2 Comments

Starting the call focused on the Internet of Things

This article is a follow-up to an earlier article on the Community Blog: Women in technology: Fedora campus presence.

This week, we took our initiative further. We guided the new women contributors on one of the bleeding edge technologies according to their interest. Sumantro Mukherjee helped me guide the contributors. Some contributors were interested in Internet of Things (IoT) while some wanted to learn Web Development as bleeding edge. So, we decided to have two different calls in a row.

Internet of Things (IoT)

The first hangout call was on Internet of Things. The contributors were explained the meaning and the structure of how IoT is implemented. It was done with the help of a presentation prepared by Sumantro. After going through the details and theory about IoT, we talked about the Arduino and Raspberry Pi. We went through a little intro and application part of the devices. We further explained the concept with the help of a little demo of the project. The details of the call are available on our Etherpad.

FOSS Wave: Delhi, India

August 31, 2016 / sumantrom / 1 Comment

Open source is the new trend. When major corporations are moving towards open architecture by using open source tools and even pushing their internal projects into open source, it makes your contributions especially worthy. But before starting with contributing, many people face the same common set of questions. How they can start, how should they introduce themselves in the community, and where they can contribute. To answer these questions, I planned a session on free and open source software (FOSS) and Fedora at the Northern India Engineering College in Delhi, India.

During the planning phase, I got in touch with Sumantro, who is himself an open source enthusiast and contributing to various open source projects including the Fedora Project. With his help, we planned the agenda for the session and gathered the resources to conduct the session. On 12th August, 2016, this session on FOSS and Fedora was conducted to:

Answer these questions
Bring up new people in the open source arena
Show where they can contribute, learn and make an impact

Source: https://www.youtube.com/watch?v=mGW2K22cECo

Modularity Infrastructure Design

August 25, 2016 / cpacheco / 1 Comment

Co-authored by Courtney Pacheco and Ralph Bean

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

Introduction

Source

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

New Taskotron tasks

July 27, 2016 / mkrizek / Comments Off

For a while now, Fedora Quality Assurance (QA) is busy with building Taskotron core features and didn’t have resources for additions to tasks that Taskotron runs. That changed a few weeks back when we started running task-dockerautotest, task-abicheck and task-rpmgrill tasks in our development environment. Since then, we are happy with the results of those tasks. We deployed them to the production instance last week. Please note that the results of those tasks are informative only. Let’s introduce the tasks briefly.

Introduction to Modularity

July 25, 2016 / cpacheco / 4 Comments

What is Modularity?

http://farm8.staticflickr.com/7103/7231460208_58dec1c81c.jpg

Source: StaticFlicker

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.

Port a package to Python 3: Parselmouth badges

Fedora needs you to port a Python package!

July 15, 2016 / Miro Hrončok / 15 Comments

Fedora is always moving forward and that means switching to Python 3. There are plenty of upstream projects that already support Python 3. Unfortunately, they are often not packaged in Fedora. We try to keep track of such cases and more in the Fedora Python 3 Porting Database. There, you can see these packages marked with a blue color and listed on the page for Mispackaged packages. Get up to three Fedora badges for updating spec files to support Python 3! Join the porting party, help us move to the future and get your reward. We can port it, but not without your help!

Join the Python 3 Porting Party!

Heroes of Fedora (HoF) – F23 Final

July 7, 2016 / adamwill / Comments Off

Heroes of Fedora 23 completes, with a look at the heroes of Fedora 23 Final testing.

Wrapping up the Heroes of Fedora for Fedora 23, after the Alpha and Beta posts, it’s time to celebrate all those who contributed to Fedora 23 Final testing! As usual, we’ll be looking at Bodhi feedback on updates, release validation tests, and bug reports.

Another way to push package updates to stable in Fedora Bodhi

June 17, 2016 / trishnag / 1 Comment

This article was originally published on Trishna Guha’s blog,

Bodhi is a web application that facilates the process of publishing package updates of Fedora. Once a package is submitted to Bodhi it goes through various stages: Pending, Testing, Stable, Obsolete. The details can be found here Package States.

There exist two types of policies in Bodhi, using any of them maintainers can publish their package updates (Pushing updates to Stable from Testing). Updates Policy documentation: https://fedoraproject.org/wiki/Updates_Policy

Updates Policy in Bodhi:

Manually push to stable based on time :
- Auto-karma is disabled.
- Update spends 14 days in testing.
- Maintainer pushes the update to stable manually.
Automatic push to stable based on karma :
- Auto-karma is enabled.
- Stable Karma threshold is reached.
- The update is pushed to stable automatically.

Why modularization matters to Sys Admins

April 5, 2016 / langdon / Comments Off

As a systems administrator, you generally worry about two things. First, the security of the systems you support. Second, that the applications you run work as designed. You would like to do those two things with as little effort as possible, however, you want to be aware of and balance the risk inherent in meeting those goals.

Enter Fedora. Fedora curates the libraries and applications that are available to install on your local system(s). Fedora makes the promise that as soon as possible after the release of a patch or a new version of a library or an application it will make it available to you as a system administrator. However it does this by ensuring the sanctity of individual libraries. Effort is also made to ensure that dependent applications are also verified which consume that library.