The Fedora 18 Virt Test Day is this Thursday, November 1st. That's two days
away! The test day landing page is here (still being expanded):
If you're interested in trying out some new virt functionality, we've got
step by step instructions for:
* Using snapshots to backup disk images of a live VM with no VM downtime
* Assigning a physical USB3 device to your VM
* Assign a local USB device to your VM, even if the VM is on a remote machine!
* Setting disk IO bandwidth limits on your VM
* Suspend and Hibernate your VMs
* Enabling the PV EOI performance optimization for your VMs
* Using kernel syscall filters (seccomp) to further secure your host
against VM exploits (currently busted but we are working on a fix)
Of course, maybe you don't care about new features. We still need you! The
test day is the perfect time to make sure your virt workflow is working fine
on Fedora 18, as there will be several developers on hand to answer any
questions, help with debugging, provide patches, etc. No requirement to run
through test cases on the wiki, just show up and let us know what works (or
If you plan on showing up to the test day, add your name to the participant
list on the wiki, and on thursday, pop into #fedora-test-day on freenode
and give us a shout!
test-announce mailing list
My name is Chandler Wilkerson and I'm a long time Redhat/Fedora user,
admin, and in the last few years at my current job, I've become an RHCE,
an RHN satellite admin, and then an RHCA.
My motivation on getting into Fedora packaging is to help maintaining
the AlienArena package, as I'm an avid player of the game and noticed
that the packages haven't followed the recent burst of releases this year.
I've managed some early scratch builds of an updated version:
I've also probably broken protocol by talking to Tom directly about this
first, so I'm just trying to get in and do things the accepted way now.
Research Computing Specialist, RHCA
Join us on irc.freenode.net in #fedora-meeting-1 for this important
meeting, wherein we shall determine the readiness of the Fedora 18 Beta.
Thursday, November 01, 2012 @17:00 UTC (13:00 EDT/10:00 PDT/18:00 CET)
"Before each public release Development, QA and Release Engineering meet
to determine if the release criteria are met for a particular release.
This meeting is called the Go/No-Go Meeting."
"Verifying that the Release criteria are met is the responsibility of
the QA Team."
For more details about this meeting see:
In the meantime, keep an eye on the Fedora 18 Beta Blocker list:
Reminder: Fedora 18 Beta readiness meeting follows the Go/No-Go meeting
in two hours (19:00 UTC, 3pm Eastern, 12pm Pacific).
Btw. please check time against UTC as we are during the daylight saving
time change period...
test-announce mailing list
I'm working in a package which ships a udev rule in /lib/udev/rules.d
I haven't seen any guidelines about this, and I wonder if I must do a
udevadm control --reload in %post
I have checked other packages with udev rules but this command is not
issued, is this correct?
I'm David Vossel.
First off I have an ulterior motive with this self introduction I'd like to get out of the way quickly. I need a package sponsor. I have volunteered to help maintain both the pacemaker and libqb upstream packages but need someone to and add me to the packager group before I can attain those roles. I have been doing RHEL packaging for a couple of months already, so I should be of very little burden to anyone willing to guide me. Your help with this is greatly appreciated :)
With that out of the way here is a little about me, where I came from, my past experience, and what I'm up to these days. tl:dr at bottom.
I stumbled into the open source world back in 2008 as I was finishing my undergraduate degree in Computer Science. At the time I was applying for jobs with the hope of lining something up so I could make the smooth transition from school right into employment. As I progressed through the interview process at several companies I remember feeling somewhat discouraged with what I was running into.
Here I was exiting the academic world where ideas and knowledge are something to share and celebrate, to this market place where it appeared groups even within the same company struggled to communicate with one another. Everywhere I went I gathered this underlying sense of, "This is my turf, my peice of the pie, and how I implement this is none of your business. Not only do I want to do this my way, I don't even want you to see what I'm doing until I'm done because criticism just slows me down." I found the result of this sort of process was kind of hilarious. All these groups would come together with their rigidly designed pieces of the project and the first thing that happens is they realize something doesn't work... or everything works, but it needs to work slightly differently. From there, some sort of agreement is made about what needs to change what and whoever is involved goes off into hiding to update their project. Then inevitably what should have been a simple change ends up taking weeks, and no one knows why... Everyone gets back together after an extended period of time to find another change needs to be made and so goes the process. I believe this cycle might very well fall under the literal definition of insanity. At this point I was starting to seriously reconsider my career choice... but one day rather quickly all that changed.
I was interning somewhere at the time when by some stroke of luck a lucid product manager picked up on my struggle and took me aside. It was like he was imparting some sort of forbidden wisdom on me. He wouldn't even talk about it in the hall way out of concern someone might pick up on what he was about to say. Basically he said he knew my type, and knew I didn't belong here. He made some phone calls and the next thing I knew I was interviewing at this little company that sponsored the development and maintenance of the open source Asterisk telephony project. I had used linux in the past during school, but didn't quite get the whole open source thing yet.
I'd like to think my reputation and referral was strong enough that a technical interview wasn't warranted, but honestly I have no idea why this happened. Instead of spending the interview process going through a list of questions to determine if I was technically competent, they sat me down in a room and we talked about open source for a couple of hours. My mind was blown. I had never experienced the level of collaboration and knowledge these guys were immersed in daily. I remember seeing the commit mailing list and watching as people all over the world contributed code to the project. I remember watching one of the guys in the office talk about how some professor in Italy saw some commit he made the other day and offered some useful criticism. It was simply brilliant and after witnessing the potential such a community can make on the world I felt somewhat embarrassed I hadn't discovered the true value of open source until then... So I took the job and began my journey into open source :)
>From that point I worked on the Asterisk project for 3 years. Some of my notable contributions to the project include the new ConfBridge audio/video conference engine, designing the new media framework architecture, and re-architecting many of the complexities within Asterisk's concurrency model to improved both performance and stability... those may or may not have been bullet points directly taken off my resume :) Eventually I became the Asterisk technical team lead and was the go to guy for all things architecture related.
>From there I decided it was time to broaden my knowledge outside of Asterisk. I heard about an opening at Red Hat that would give me the chance to work on some high availability software. One of the aspects of Asterisk's design that somewhat frustrated me was its monolithic design structure. This led to all kinds of challenges with scalability. Given that processors are going wide and network speeds are crazy fast, I felt like it would be a good idea for me to get some hands on experience with component driven design. That's exactly what I got when I began work on the Pacemaker project earlier this year. The stacked approach to high availability used in Fedora is brilliant and I feel blessed to be involved. So far I've had the opportunity to implement a new version of the lrmd component Pacemaker uses to manage each node's local resources, and make several design improvements to the STONITH fencing component.
It is kind of difficult to wrap up a story that has only just begun, but this is where it ends for me at the moment. If you ever want to chat about high availability, or even Asterisk, I usually hang out in #fedora and #linux-ha. Thanks for reading, and I look forward to continuing to collaborate with you all :)
tl:dr - I worked on Asterisk for a few years. Now I work on Fedora's High Availability stack. I need a sponsor to add me to the packager group.
-- David Vossel