The post PulseCaster 0.9 released! appeared first on The Grand Fallacy.

It says… It says, uh… “Virgil Brigman back on the air”.

The Abyss, 1989 (J. Cameron)

OK, I feel slightly guilty using a cheesy quote from James Cameron for this post. But not as guilty as I feel for leaving development of this tool to hang out so long.

That’s right, there’s a brand new release of PulseCaster available out there — 0.9 to be exact. There are multiple fixes and enhancements in this version.

(By the way… I don’t have experience packaging for Debian or Ubuntu. If you’re maintaining PulseCaster there and have questions, don’t hestitate to get in touch. And thank you for helping make PulseCaster available for users!)

For starters, PulseCaster is now ported to Python 3. I used Python 3.6 and Python 3.7 to do the porting. Nothing in the code should be particular to either version, though. But you’ll need to have Python 3 installed to use it, as most Linux bistros do these days.

Another enhancement is that PulseCaster now relies on the excellent pulsectl library for Python, by George Filipkin and Mike Kazantsev. Hats off to them for doing a great job, which allowed me to remove many, many lines of code from this release.

Also, due the use of PyGObject3 in this release, there are numerous improvements that make it easier for me to hack on. Silly issues with the GLib mainloop and other entrance/exit stupidity are hopefully a bit better now.

Also, the code for dealing with temporary files is now a bit less ugly. I still want to do more work on the overall design and interface, and have ideas. I’ve gotten way better at time management since the last series of releases and hope to do some of this over the USA holiday season this late fall and winter (but no promises).

A new release should be available in Fedora’s Rawhide release by the time you read this, and within a few days in Fedora 31. Sorry, although I could bring back a Fedora 30 package, I’m hoping this will entice one or two folks to get on Fedora 31 sooner. So grab that when the Beta comes out and I’ll see you there!

If you run into problems with the release, please file an issue in Github. I have fixed mail filters so that I’ll be more responsive to them in the future.files

Photo by neil godding on Unsplash.

The post Flock 2019 in Budapest, Hungary. appeared first on The Grand Fallacy.

Last week I attended the Flock 2019 conference in Budapest, like many Fedora community members. There was a good mix of paid and volunteer community members at the event. That was nice to see, because I often worry about the overall aging of the community.

Many people I know in Fedora have been with the project a long time. Over time, people’s lives change. Their jobs, family, or other circumstances move them in different directions. Sometimes this means they have less time for volunteer work, and they might not be active in a community like Fedora. So being able to refresh my view of who’s around and interested in an event like Flock was helpful.

Also, at last year’s Flock in Dresden, after the first night of the conference, something I ate got the better of me — or I might have picked up a norovirus. I was out of commission for most of the remaining time, confined to my room to ride out whatever was ailing my gut. (It wasn’t pretty.) So I was glad this year also to be perfectly well, and able to attend the whole event. That was despite trying this terrible, terrible libation called ArchieMite, provided by my buddy Dennis Gilmore:

I’m not going to exhaustively list all the sessions I attended, although I made it to virtually every hour of the event. Here are some of the highlights.

Plenary sessions at Flock

It’s always good to hear our project leader Matthew Miller talk about Fedora. I was happy to see the steadily rising popularity of Fedora especially as Linux distros overall seem to be flattening. A lot has been going well with both quality and reliability of the operating system, and it’s reflected in the graphs Matthew showed.

Speaking as a (very!) part time contributor, I also would have liked to hear a rallying cry or two, something aspirational and specific. But I also understand that Fedora’s resources out of Red Hat haven’t increased a lot over the last couple of years. And it seems like the evolution of tech that Fedora is incubating is doing well overall. So even without a “moonshot” type goal I’m still satisfied that the project is on the right track for the future.

The talk by Cate Houston from Automattic — makers of WordPress, which powers fine blogs like the one you’re reading, as well as Fedora Magazine — on building stronger teams was good as well. I did feel it lacked a bit on tactical approaches for community projects like Fedora. But there were plenty of lessons to chew on. One of my favorites I RT’d here.

I also thought about her talk in the context of Fedora’s institutional knowledge. We don’t always do a good job of capturing lessons learned. Sometimes we have retrospectives about things we do. As long as we pull out some improvement from each of these, and put it into play, in the long run we should end up with better processes and practices. It’s up to each of us to drive that treadmill of constant improvement.

My Flock appearance: RHEL 8 panel

I spoke on a panel with Brendan Conoboy (development coordinator for RHEL 8), Denise Dumas (Red Hat’s VP of Platform Engineering), and Aleksandra Fedorova (team lead for continuous integration efforts in Fedora and RHEL). We talked about the road to RHEL 8, and what we learned about differences in Fedora and RHEL.

One major point I made was about the huge weight a “secret schedule” puts on the Fedora community and project as a whole. I experienced this first hand as FPL, and I know Matthew Miller has too. It’s not always clear why certain features are important when they land in Fedora. Now that Red Hat has publicly committed to a new major release of RHEL every three years, we know that RHEL 9 will hit the streets in spring or summer 2022. That, plus knowing that Fedora 27/28 were vital to RHEL 8, gives us an idea about critical upcoming Fedora releases for RHEL 9. Think three years ahead, and it’s clear to me we’ll see efforts on technical change accelerating up through Fedora 33/34 (my estimate, not gospel).

Modularity

I also attended several sessions on Modularity. One of them was Merlin Mathesius’ presentation on tools for building modules. Merlin is on my team at Red Hat and I happened to know he hadn’t done a lot of public speaking. But you wouldn’t have guessed from his talk! It was well organized and logically presented. He gave a nice overview of how maintainers can use the available tools to build modules for community use.

The Modularity group also held a discussion to hear about friction points with modularity. Much of the feedback lined up well with other inputs the group has received. We could solve some with better documentation and awareness. In some cases the tools could benefit from ease of use enhancements. In others, people were unaware of the difficult design decisions or choices that had to be made to produce a workable system. Fortunately there are some fixes on the way for tooling like the replacement for the so-called “Ursa Major” in Fedora. It allows normal packages to build against capabilities provided by modules.

Zuul + composes

There was an excellent presentation on Zuul, the Python-based CI system used by OpenStack. It seems quite mature at this point, incredibly flexible, and possibly of interest to Fedora. However, there are a number of CI systems in use. I’m not sure how many CI system maintainers were around for this talk. But I hope they will take note of the video when it’s issued and see if it’s worth investigating.

Lubomír Sedlá? presented on how to make faster composes. In large part, we stand to gain the most by not producing as much as we have been. One does wonder why we make so many separate expressions of the OS intended for servers, desktop computers, or other footprints.

Lubomír and others are looking at ways that we could make some composing work available to the community. Currently you can only compose with a tight connection to a very large (and understandably sensitive) NFS storage area where we keep package builds. Being able to make that more available to the community would be helpful. I’ve been wondering for a while why we can’t publish our builds somewhere besides a storage location that others can’t access in a read-only mode as freely (like an Amazon EBS or S3 store, or something like that not at Amazon). But Lubomír also talked about work in progress on the composer code, too, and it’s good to see that no one considers the compose “good enough, let’s not try to improve it.”

CI

Another highlight was Dominik Perpeet’s talk on the CI Objective in Fedora. There are a number of people working on bringing the benefits of a CI/CD approach to Fedora. Dominik’s group plays a central part in that. We want to have two orders of magnitude more people run Rawhide daily than right now. A good CI process, along with properly iterating on that process, gets us closer to that goal. Education, awareness, and a shared sense of responsibility across package maintainers will, too! We don’t have to give up daily usability to be able to land new things in Rawhide. But we will need to work better together as a project. I think we’re on the right track but more is yet to come.

In closing

I attended a lot more talks, but I’m running out of time to get this blog out and feel like I added to the knowledge pool about Flock proceedings. Many, many other sessions happened at Flock — too many for any one blog to cover! I hope to see the videos soon on the Fedora YouTube channel, and then you too can see some of the fantastic work being done by contributors around the project.

In closing, I want to sincerely and deeply thank Jen Madriaga, Veronica Cooley, Matthew Miller, Brian Exelbierd, Ben Cotton, and all the folks who helped organize and run such a great conference. This was one of the best Flock events in recent memory and it happens through the hard work of organizers. Thanks to all of you, and hope to see you next year at Flock on this side of the pond!

The post Fedora BoF report from Summit 2018 appeared first on The Grand Fallacy.

Last week I attended the Red Hat Summit 2018. There I interacted with customers, partners, community leaders, and some friends from around Red Hat. I enjoy going every year and look forward to it, despite the exhaustion factor. This year included a fun event for Fedora — a birds of a feather (or BoF) session. Read on for my report.

FPL Matthew Miller arranged the BoF, and several people assisted there, including Brian Exelbierd and me. Several core contributors attended as well. But out of the 30-35 people who attended, the vast majority were not community members, but rather people interested in or using Fedora.

We split into groups and ran each in a Lean Coffee style. My group included about 12 or so people. I don’t recall every topic in our prioritized cards, but notable ones included:

• Use of legally encumbered codecs
• NVidia drivers
• How to get started contributing
• Whence the minimal install

Our group members voted up the codecs + NVidia topics by a factor of more than 2 over the next highest rated topic! That’s why it made me very happy to report to them that Fedora 28 includes the GNOME Software function that lets users decide whether to enable selected repositories outside Fedora.

I know a few people grumble about this function. I used to rail about the topic myself. As I’ve grown older and met more people in different walks of life, I’ve realized I no longer want to interfere with their agency to make their own choices. The BoF attendees responded well to this new feature and were overjoyed to hear about the way this is now available. I’m pretty sure we made a few instant Fedora converts on the spot.

I enjoyed the BoF overall, but this particular topic resonated with me strongly. I know how hard several of the Workstation working group members worked to make this new feature a reality in Fedora 28. This experience showed me it has an impact on people’s interest in using Fedora. If it also makes them more interested in contributing, that’s great for Fedora in the long run.

Also, I realize I haven’t written on this blog in a very long time. I’ll try not to take so long next time, but no promises. Life is very busy!

The post Better Pagure email filters for Gmail appeared first on The Grand Fallacy.

I get quite a bit of email notification from Pagure, the free (as in freedom!), Python-based git forge. I have and participate in several repos there. Pagure sends me email when there’s a new or updated issue, pull request, or commit to a repo I monitor.

Previously, all that email for me has gone into a “Pagure” folder. But Pagure offers a special header, X-pagure-project, which indicates the specific project that triggered the email. Unfortunately, Gmail’s filters notoriously lack the ability to parse arbitrary headers. This is actually a limitation of the Gmail API. Why there’s no getHeaders() call, I have no idea — but maybe it has something to do with worries about arbitrary content there.

Now, I could probably set up filters to look for mail From: pagure@pagure.io and then look in the subject line for [Project-name]. But this means I have to make a new filter for every project manually. YUCK!

Enter Google Apps Script

So I wrote my very first Google Apps Script (this script is MIT licensed).

Here’s the link, which will stay up to date.

How to use the script

To use it, you first need to connect Google Apps Scripts to your Google Drive. (Use New –> More in Google Drive, if this isn’t already done.) Then save this as a new script in your Drive.

Adjust the parentlabel value if needed. Then set a timer trigger to run the processInbox function every 5 or 10 minutes.

Make sure to remove any existing filter for Pagure notification email, so that your script has a chance to run against notifications in your Inbox.

If you’ve never used Google Apps Scripts before, it’s easy to get started. I’m living proof, since I’m not much of a developer. Here’s a quick start from Google that will help.

The post The next big things, 2017 edition. appeared first on The Grand Fallacy.

Along with several people on the Fedora Engineering team, I recently attended the DevConf.cz 2017 event. The conference has grown into an amazingly successful gathering of open source developers. Most attendees live in Europe but there were some from every continent. The coverage spanned all the big open source buzz-generating technologies. Session topics included containers, PaaS, orchestration and automation, and DevOps.

One of the most frequent topics I heard at and around the conference was CI — continuous integration. The idea of CI isn’t new in and of itself. Many open source projects put it to use already. If you do any work on Github, you’ve already seen it at work. (Also notably, OpenStack features one of the biggest and arguably most successful at-scale efforts.) However, it hasn’t taken strong root in Fedora, yet.

Based on the discussions I had and heard at DevConf.cz, that’s likely to change soon. Why? Well, for one thing, Fedora still breaks too often. This is especially (but not exclusively) true about Rawhide. But in many cases, we can easily understand these breakages. That means we can detect and prevent them before they occur. While update testing in Bodhi helps in the case of stable releases, that’s not a cure-all. That process still depends heavily on manual efforts that aren’t guaranteed. Moreover, those efforts form a gate of several days at a minimum, between building, karma, and tagging. This process no longer scales with new, fast-moving deliverables like Fedora’s edition of the Atomic Host. One size no longer fits all. We need a more flexible, automated approach.

What does that mean? For Fedora, the CI concept means gating on automated tests that guarantee some level of validity to a change. These tests are run prior to introducing changes into a tree, ostree, module, container, etc. That way, we don’t pass breakage on to the consumer.  But we can message that breakage back to the maintainer directly. The maintainer then quickly acts to fix the issues. And they see more immediate results from their fix.

We must do some work in the Fedora infrastructure to make this process work for Fedora contributors (maintainers especially). Some app work is also required to support our packaging and deliverables. We must make sure it’s easy for people to contribute to tests. Maintainers need to easily understand the status of their build requests. And of course the community must be able to continue contributing to higher levels of testing that make for a better Fedora. So CI isn’t the end of the story. It’s just another strong link in a chain of improvements.

Fortunately, we’re well situated to do great work here. For instance, the Fedora Infrastructure team already plans to front our dist-git package control with Pagure. (You probably know Pagure is a full-featured collaborative git forge.) This ensures the Fedora dist-git acts as a source for CI, tested with each new proposed change. But we believe this is unlikely to cause more complexity. Packagers can expect to use tools they already know. Furthermore, they could use the popular, effective pull request model to maintain packages and develop testing. This lowers the bar to contribution while maintaining high quality.

Another point in our favor is the entire Fedora application infrastructure has been running on the fedmsg messaging bus for years. We already can orchestrate and coordinate a huge number of automated activities around events involving our apps. Therefore a higher level of continuous integration and testing is well within our grasp.

Of course, this blog post is light on details. (What else would you expect from a manager?) ? Those details are obviously important. As the least technical person in the Fedora Engineering team, though, I’m the last person you’d want to describe them in detail. But the folks in the Infrastructure community team will be launching a series of discussions on the mailing list to explore those details.

We’re all passionate about making Fedora better. So hearing feedback from our contributors and colleagues at DevConf.cz has us very excited and enthusiastic about this next level. I encourage you to get involved and contribute constructively to the discussions!

The post Holiday Break 2016. appeared first on The Grand Fallacy.

It’s sad I don’t get more time to post here these days. Being a manager is a pretty busy job, although I have no complaints! It’s enjoyable, and fortunately I have one of the best teams imaginable to work with, the Fedora Engineering team.

Since we’re coming to the close of another calendar year, I wanted to take a moment to remind people about what the holidays mean to availability. I’m going to crib from an earlier post of mine:

My good friend John Poelstra is fond of saying, “It’s OK to disappoint people, but it’s not OK to surprise them.” That wisdom is a big reason why I like to set expectations over the holidays.

Working at Red Hat is a fast paced and demanding job. Working full time in Fedora is itself demanding on top of that. These demands can make downtime at the holiday important for our team. At Red Hat, there’s a general company shutdown between Christmas and the New Year. This lets the whole organization relax and step away from the keyboard without guilt or fear.

Of course, vital functions are always staffed. Red Hat’s customers will always find us there to support them. Similarly, our Fedora infrastructure team will monitor over the holidays to ensure our services are working nominally, and jump in to fix them if not.

Some people like to spend time over the holidays hacking on projects. Others prefer to spend the time with family and friends. I’ve encouraged our team to use the Fedora vacation calendar to mark their expected “down time.” I encourage other community members to use the calendar, too, especially if they carry some expectations or regular responsibilities around the project.

So all this to say, don’t be surprised if it’s harder to reach some people over the holidays. I’m personally taking several weeks around this holiday shutdown as time off, to relax with my family and recharge for what’s sure to be another busy year. Whatever your plans, I hope the holiday season is full of joy and peace for you and yours.

The post Wheee, another addition. appeared first on The Grand Fallacy.

I’m thrilled to announce that Jeremy Cline has joined the Fedora Engineering team, effective today. Like our other recent immigrant, Randy Barlow, Jeremy was previously a member of Red Hat’s Pulp team. (This is mostly coincidental — the Pulp team’s a great place to work, and people there don’t just move to Fedora automatically.) Jeremy is passionate about and has a long history of open source contribution. We had many excellent applicants for our job opening, and weren’t even able to interview every qualified candidate before we had to make a decision. I’m very pleased with the choice, and I hope the Fedora community joins me in welcoming Jeremy!

The post Another addition. appeared first on The Grand Fallacy.

I’m extremely happy to announce that Randy Barlow has joined the Fedora Engineering team, effective today. Randy was previously a member of Red Hat’s team working on technologies like Pulp. You can find his fingerprints in many upstream repositories as a frequent contributor. This is fortunate for our team, since Randy will be contributing both to our applications infrastructure and to our release team. His experience with Pulp may come in handy too, since it may play a part in making next-generation Fedora content available to the public. I hope the Fedora community will join me in welcoming Randy!

The post Fedora Engineering team opening, April 2016. appeared first on The Grand Fallacy.

My day job, as you probably know, is at Red Hat, where I manage the Fedora Engineering team. Our team provides engineering and design services for the Fedora Project, a collaborative community project which is the upstream source for a number of influential products. Not the least of these is Red Hat Enterprise Linux, of course.

We now have a job opening for a senior engineer in the USA to be part of our team.

About the job

Collaborating with the rest of the team, the community at large, and your colleagues in Red Hat, you’ll:

• Build tools and web services that will in turn build a more modular next-generation Fedora
• Do full-stack development, with a hand in everything from working with designers, to architecting and writing code, to deploying in test/stage/production, to maintenance and enhancement
• Automate, automate, automate all the things
• Co-create and develop our next community engagement system, Fedora Hubs
• Stay tuned into exciting work going on throughout Red Hat related to platform and other technologies
• As with all Fedora Engineering jobs, communicate openly and continually with the whole community, and build community around everything you do using open source best practices

About the Fedora Engineering team

Our team uses a lot of Python (flask and sqlalchemy currently rank highly), and we’ll be expanding outward in the future where it makes sense. We create code upstream that is widely consumable beyond just Fedora, and we deploy our work on both Red Hat Enterprise Linux and Fedora.

We do that work openly: collaboration via git repositories, rapid and constant communication via IRC, frequent discussion through our mailing lists, and gathering and building community around our work. Simply put, we love open.

Who we’re looking for

The right candidate is a team player, positive and constructive, fully engaged and passionately committed to delivering results with their colleagues, wherever they might be. This is a senior position, so we’re looking for someone who’s a proactive, detail-oriented self-starter, and has the ability to lead from the side on a few projects. We want you to be really good at Python and being Pythonic, and hopefully have some similar high-level language experience like Ruby or Java where you can help us grow, too.

Not interested in working in a Red Hat office? No sweat. We’re a distributed team, and this job is perfect for an experienced remote candidate. Remote doesn’t mean aloof, though. You need to be somewhat of a people person to crush this job, because good open source means collaboration. We meet up at least once a year as a team for Flock, but we work together constantly online.

I would be remiss in not pointing out this position back-fills some mighty big shoes. That’s why I’ve outlined some ideas for who we’re looking for in this post. That being said, you’ll also be working for a manager who’s a super guy. Just check the sidebar of this blog for proof. In all seriousness though, we all care about our teammates’ success, so you’re never on your own when you need a hand.

And don’t forget, Red Hat is consistently rated one of the best and most innovative places to work.

Enough already, where do I apply?

Does this job sound interesting to you? Make sure you read the full description of the job, and then apply online.

The post Contributing to Pagure made easy. appeared first on The Grand Fallacy.

I don’t get as much of a chance these days to do things like patches or other technical contribution. But I had some time free the other day and used it to stick my hands directly into a cool project, Pagure (pronounced roughly “pag-yOOR,” or listen here). You may have read about Pagure in this Fedora Magazine article a few months back.

It was tremendously easy to get Pagure, fix a bug, test the fix, and contribute it back (see my pull request here). I specifically looked for “easyfix” bugs, since I knew I didn’t have a lot of time to spend to help. So I decided to work on this issue, a button showing up when it shouldn’t.

First I forked the repo in Pagure. Then I cloned my new fork, and set it up as documented in the README. In the clone, I checked out a new branch using the issue number as a name, issue839.

To track down the fix, I ran the app locally and duplicated the error. I looked at the CSS style containers for the button and some of the surrounding elements. Using that information, I did a text search on the code to find the file that was generating the button. Then I simply applied some logic to find the fix for the problem, even though I wasn’t really familiar with the code involved.

Thankfully Pagure has a test suite, so I could also check that my fix didn’t break any of the tests. Then I committed and pushed my changes, and made a pull request using the button in Pagure’s web page.

I also learned something useful. Since I forked the repo to do my fix and make a pull request, if I force-pushed changes using git to my branch from which I made the pull request, the pull request was automatically updated with the changes! This is probably expected by people who do this all the time, but since I’m new at it, I was excited.

Bugs like this are something that just about anyone with a small amount of beginning programming skill could fix. Pagure even has other bugs like this waiting for people to handle. Maybe one of them is waiting for you! ?