We will be holding a CentOS Dojo at Facebook, Menlo Park, (San Francisco area) on April 24th. This is the Friday immediately before Red Hat Summit, so you can tack a few extra days on the front of your Summit trip and see how CentOS is used at Facebook.

Details of the event are available at https://wiki.centos.org/Events/Dojo/Facebook2020

The Call for Presentations is now open. We're looking for technical talks about stuff that is in and on CentOS. You can see examples of the content we have run in the past at https://www.youtube.com/thecentosproject

88% of our attendees in Brussels said that the content was about right, while 12% said it was not technical enough, if that helps set your expectations of what talks to submit.

The CFP closes on March 15th, and space is extremely limited, so don't wait. Get your talk submissions in now.

CentOS Dojo, Brussels, January 31, 2020
Grant Place Marriott
Event details: https://wiki.centos.org/Events/Dojo/Brussels2020

Just the facts:

Registered: 125
Attended: Approx 110 (12% no-show)
13 sessions. Slides and video will be posted at the above address over the coming 2 weeks.

Event report:

We held the annual CentOS Dojo ahead of FOSDEM again this year. We were at the Grand Place Marriott for (I think) the 4th year. (Maybe 3rd?) This venue is always very helpful in supporting our event, and addressing problems as they arise. Recommend we keep doing it there for next year.

We “sold out” of our 125 tickets by 3 weeks before the event. Leading up to the event, I encourage registered attendees to cancel their tickets if they were not, in fact, attending, and I saw probably 30 cancelations, all *immediately* followed by new registrations. As a result, our no-show rate was very low. Note that the 110 attendees is an estimate based on an after-lunch count, and is *probably* low, as people came and left throughout the day.

I would consider running more tracks, except that getting talks for the event was exceptionally difficult this year. I’m not sure why that was, but I need to do more direct talk solicitation (ie, asking individuals to give specific talks) ahead of next year’s event.

We started the day with a session on CentOS Stream, which was standing room only, and generated some really good questions. People seem very interested in Stream, and seem to get the concept. Related: Facebook said, in their talk, that they are retiring CentOS 7 and moving their entire infra over to CentOS Stream. That’s *millions* of servers. So … wow.

We saw a huge spike in Twitter engagement on the 31st (roughly 9 times usual) fading a little on Saturday (roughly six times usual) and Sunday (about 3 times usual). Historically, we’ll see another spike as we start posting the slides and videos in the coming days.

During the course of the day, we arranged for upcoming CentOS Dojos at CERN (October 23rd) and Facebook (tentatively, April 24, which is *really* soon). Details coming to CentOS news channels near you hopefully by the end of this week.

We added a new feature this year - we had a room where attendees were encouraged to go to discuss their CentOS experiences with Karsten Wade. These conversations were confidential, and encouraged candid feedback about what was broken, what they’d like to see done in the coming year, challenges they face in the community, and so on. We hope to see some feedback from Karsten about this in the coming days.

Takeaways:

This event is definitely worth doing. The attendees tend to be the core of our project, and other deeply technical people using CentOS. The hallway track is always active, showing that people come as much for the interactions as for the technical content.

The struggle to find content, though, is troubling, and something that we need to work on throughout the year, rather than just during the CFP. My impression is that people don’t think that what they’re working on is of general interest. However, feedback from actual talks is that our audience really wants to see the every day stuff (here’s how I made my life easier on a normal day at work) is every bit as interesting as the cutting edge talks (here’s a fancy new thing that might be useful to you 2 years from now). So, reminder to self: Solicit these talks all year long, as you see interesting *practical* things being discussed on the lists, not just the shiny new stuff.

Why?

The current logo has a long history, and is well recognized, but the design is essentially 15 years old.  There have been comments on the mailing list that the brand should be updated. The logo also has a lot of colors which makes printing and embroidery more expensive, and sometimes leads into color matching issues as well.

CentOS project has also grown to be more than just a Linux distribution. The Special Interest Groups, CentOS Stream, and other sub-projects could also use a related logo, and we thought it would be a good time to update the branding to reflect that.

As CentOS Stream needed some kind of a logo, we had the Red Hat brand team create some proposed logos for Stream announcement. At the same time we started to feel that it was the right time to refresh the logo and branding as well, and that the process should happen openly in the community.

How?

We shared the Stream logo design files with the centos-devel list in November, which started a good collaboration with me and Alain (who has been doing great work on the current logo and brand style wiki pages) and we quickly realized, that we need to take the design idea brainstorming away from the developers mailing list to avoid spamming everyone with attachments (or risking possible broken links to images late in the list archives) - so we started a discussion in the CentOS Artwork issue tracker.

This lead to a lively and active collaboration, and we attracted also brokenkeyframe to contribute. We went through several ideas, some better than others, and settled into a stylized version of the original chaos symbol of the CentOS logo, which keeps the history alive, while making it more modern.

The logo is a single color, which makes it easy for embroidery for example, but also lets us have the logo with a photo or texture as background. The corners of the chaos symbol are slightly rounded to give it a modern touch, and we also updated the font to match the style of the symbol.

The font is called Montserrat, originally created by Julieta Ulanovsky, a designer from Argentina. Montserrat is an effort to celebrate and preserve the historic signs and lettering found in the Montserrat neighborhood of Buenos Aires. Montserrat is a beautiful typeface with several variants, and it is licensed with the libre SIL Open Font License. Julieta had a successful Kickstarter project to fund the development, and since then the project has been updated and extended by a community of collaborators. The Kickstarter page has a nice video introduction, if you are interested in typography or inspiration behind the project.

We also thought about sub-project logos (Stream, the distro itself, various Special Interest Groups) and worked on a logo template system for those.

The work will be presented to the CentOS governing board soon, but we wanted to share our current progress (and the path that lead to it) with all of you. It is likely that not so many of you have actively followed our progress on the issue tracker.

We will announce this blog post also on the CentOS developers mailing list, and I encourage you to share your feedback there, instead of commenting on this post, or on the above git issue, which we wish to keep on the topic of design, so we can focus on the task better. We’ll be sure to read your comments on the mailing list and take them to heart.

Also, I want to thank everyone who contributed and shared their thoughts and feedback!

About this document

This document lays out a problem statement, requirements, and constraints according to the Open Decision Framework. The aim is to arrive at a transparent decision about the future of a git forge for the communities that represent the platforms that the Community Platform Engineering (CPE) team manages. Those communities are the CentOS and Fedora platforms and also include the Red Hat Enterprise Linux (RHEL) platform from a tooling and integration perspective. This document is the first in a series of documents capturing the conversation about the problems we face and driving the conversation to implement the decisions captured.

Problem

The problem statement for this ODF can be broken down into a number of disctinct problems. They are listed in no particular order or priority:

CPE Mission Statement

The Community Platform Engineering (CPE) team have a mission statement to support the infrastructure and services that build and deliver platform artifacts. The mission statement aims to focus the team’s work from overcommitting to work, running multiple projects in a disconnected manner and to ultimately provide focus and value for our Communities. The remit of the team needed to be defined to allow the team to both manage the workload and the expectations.
Using this definition, the current git forge, Pagure, does not align with what CPE can focus on from both a roadmap development perspective and the operational requirements that such a service demands long term. While Pagure was historically driven by the CPE team, developing a gitforge is outside of building and delivering platform artifacts. [See the later sections for more focus on this.] A self-hosted and self-developed git forge is not required to build and deliver platform artifacts.
While we can make exceptions to the mission statement, we first need to know why we should consider a specific exception. This helps justify the inclusion and subsequent prioritisation of work. We recognise that Pagure is deeply integrated into our daily workflows and is used extensively by the Community. This is the reason the CPE team has not re-examined this commitment, and is a primary driver to openly discuss the team’s and community’s requirements for a git forge.

Development work on Pagure

The CPE team has been unable to commit a development team to Pagure for several months now. This situation is unlikely to change based on our current known priorities.
Historically, Pagure was maintained by individuals (including members of the Fedora community who aren’t on the CPE team) where spare cycles allowed. However, CPE’s mode of working is now that of feature teams, removing the siloed contributions in favour of building sustainable team practices. The feature roadmap for Pagure, however, cannot be executed solely by the CPE team, since the feature requests need to be weighed against the team’s other priorities.
Pagure represents one app out of our current ownership of 100+ code bases. Therefore progression of the roadmap is not guaranteed and certainly not at the pace seen previously. Similarly, bug fixes and enhancements are currently on a best-effort basis. The code is therefore frozen from a functionality perspective pending the outcome of this ODF.

Operational considerations of Pagure

Every line of code and application CPE supports as a team has a cost burden for maintenance and uptime. Pagure is highly-connected to numerous services that are critical to successfully running services that CPE and the community need and support. Therefore, the team must look at long term maintenance including bug fixes and server maintenance as requirements.

At the same time, integrations that already exist in Pagure may need to be created for another git forge, which is a cost as well. This also needs to be fully considered by the team as part of the requirement gathering.

Another major consideration to operationally own an application is its performance and scalability. A git forge may have key requirements for uptime, availability and responsiveness for end users. The current scalability profile of Pagure is unlikely to substantially change as it is resourced today – while the consumption profile of the user base and interconnected applications is likely to increase.

History of gathering requirements

TThe original purpose of Pagure was to mirror the functionality of popular git forge solutions that were available at the time (when most were nascent). Pagure’s feature enhancements were driven by community needs and the team’s viewpoint of where a git forge should go. The team has not solicited requirements in a holistic way from its users and the community, and its internal customers have mainly consisted of the team itself.

However, we also recognize that the feature gap between Pagure and some other forges is substantial and growing. Without either a dedicated development team, or stealing resources from other priority initiatives, it will be almost impossible to close those gaps. Depending on the consumers’ requirements, we recognize this could put Pagure in an untenable situation versus other solutions.

This makes gathering a full set of requirements even more critical. If we fail to capture requirements completely, this discussion is very likely to happen again, only more urgently and with less time for the team to plan and react.

Problems we’re not trying to solve

Feature gap between various git forge solutions

This conversation does not focus on whether Feature X exists in Forge Y or Forge Z. Instead it focuses on functional and non functional requirements for a git forge in general.

CPE time and resourcing investment

This conversation does not focus on how the CPE team invest their time and limited resources. That is not a factor in this discussion.

CPE Mission Statement

This document does not focus on the CPE Mission Statement or whether a git forge should fit that Mission Statement.

Who is making the decision?

The decision will be made by the management of the CPE team with careful consideration of the requirements for both the Fedora and CentOS communities as well as the needs of the team. The CPE team is the group that manages the integration of services and tooling with a git forge solution on behalf of our communities, and will choose the most sustainable, functional, and scalable option to improve our workflows long term.

Choices Available

There exist three choices for such a solution. Github, Gitlab and Pagure. There are no other forges that we could find that had both the product maturity and standing in open source communities, therefore no other solutions are under consideration as the three choices here represent the main git forge solutions on the market. The team will use the requirements gathered to make an informed decision on which of the 3 to pursue.

Who has input into the decision?

Please see the section on Stakeholders below.

Objectives

Identify functional requirements of a git forge that end users and stakeholders need

The goal is to outline what is needed from the day to day perspective of:

• Using a git forge solution.
• Maintaining a git forge solution
• Future proofing a git forge solution

Requirements are welcome from members of the CPE team and the groups identified as being impacted by such a decision.

Identify non-functional requirements of a git forge that end users and stakeholders need

Examples of non-functional requirements include but are not limited to performance, scalability, availability, reliability, maintability, and capacity. The goal here is to include considerations of this nature from any group impacted by this decision.

Make an informed decision on the future of our git forge solution

Upon gathering the requirements of a git forge solution, the intention is to:

• Examine requirements gathered versus available git forges
• Examine the cost of each forge from the CPE teams perspective. This cost is not exclusively a monetary amount and includes maintenance and development costs and trade offs versus our teams roadmap

To be clear, the outcome here may be a decision to invest heavily in Pagure to meet the requirements or it may be to opt for another git forge to meet the requirements. No option is off the table.

Who may be impacted

• Package maintainers for Fedora, EPEL, CentOS Linux, and CentOS Stream
• Developers of apps/services for infrastructure that integrate via Pagure
• The CPE team
• Developers (and users) that use Pagure for their upstream source
• Members of the Fedora and CentOS communities who currently use Pagure as a source repository or ticket system

Who are the key stakeholders

While we apprecaited that all individual voices matter, for a more sane approach to gathering requirements we will identify key stakeholders to collate and present a singular view of their representation.

• Fedora Council will represent the individual community members of the Fedora Project
• CentOS Board will represent the individual community members of the CentOS Project
• Paul Frields will represent the RHEL perspective
• Aoife Moloney will roll up the requirements of the CPE team as our Feature Driver.

How will information be gathered and disseminated?

It is recommended that both Fedora Council and CentOS Board gather input and present their concerns in a manner that is consistent with how their communities work. The RHEL and CPE requirements will be gathered through Red Hat communication mechanisms and presented publicly via a HackMD file to ensure transparency in their source. This will be published and distributed in due course. Additionally, a live video call and associated IRC meetings will be held and advertised in advance to discuss the requirements, talk about concerns and address any questions. We want transparency to be at the heart of this decision.

Timeline of Phases

• January 13th 2020 sharing of the ODF for consideration within CPE Team
• January 20th 2020 sharing of the ODF for consideration to Community
• February 10th 2020, closing of comments from stakeholders which marks the end of the Ideation Phase
• CPE Management evaluate the requests and where necessary may instruct the CPE team to begin a Planning and Research phase to take in the inputs from the Ideation Phase
• CPE design, develop and test proof of concept plans based on the decision made by CPE Management and share this with the Community
• CPE closes the ODF with a decision made and a path forward for our git forge

On behalf of the Board, a group of us is working on an update to the CentOS Project goals that were originally laid out in 2014 and are online at centos.org/about. We’re hosting informal user and contributor interviews in a room throughout the day at the CentOS Dojo later this month in Brussels.

Please join us and share your open and honest experiences with CentOS the project, technologies, community, and so forth. We’d like to hear from you and, ultimately, see how your input can inform the goal-setting process and outcome. You are welcome to bring your questions about community, governance, project direction, other strategic thoughts, and so forth.

If you're interested in participating in this informal opinion-gathering, please come see Karsten or Rich at the Dojo, or at the CentOS table at FOSDEM.

/signed Karsten Wade on behalf of CentOS Board and other co-authors