Getting the jump, no. 14.

With only two days left until Fedora 14 release, I went ahead and upgraded the behemoth in my home office, a Dell XPS 730x workstation, to the new “Laughlin” release. Once again I used preupgrade to do the bulk of the work. Because there’s not an official preupgrade update out yet, I customized a releases.txt file to include a definition for Fedora 14, setting the baseurl and installurl values to a local mirror in my home network where I was mirroring the development/14 tree. (I probably should do something with MirrorManager to make my local network accept mirror requests locally, but I haven’t got a Round Tuit since I updated my server.)

Normally a user wouldn’t have to do this, of course. I only did it because I was impatient and didn’t want to wait. Most users could simply run preupgrade and click next a few times to do everything they want.

The key to preupgrade happiness is making sure that you have plenty of space in your /boot partition, and wherever you’re keeping /var/cache/yum. You can run df -h /boot /var/cache/yum to find out — You’ll probably want a few hundred MB free* in /boot, and 2 GB in /var/cache/yum should suffice, depending on how much stuff you have installed on your system. Even with quite a lot installed on my system, I only needed 1.2 GB to store packages, and had about 4.4 GB free, so it was smooth sailing.

Incidentally, this is where Logical Volume Management (LVM), as opposed to old, simple physical disk partitions comes in so handy. You can use LVM to adjust your partitions to give more space where you need it, when you need it, and in cases like this it’s an invaluable Fedora feature.

Once preupgrade downloaded everything it needed, it presented a dialog telling me I could reboot any time to finish the upgrade. After saving my work, I rebooted and the upgrade process started with no intervention needed. For 1549 packages, the final step of the process — upgrading the packages after rebooting — took approximately 75 minutes. A yum update process performs a lot of work beyond simply copying files onto the disk, to ensure your system’s integrity, so this extra time is to be expected. I like to wander off and work on something else while preupgrade runs, so the computer’s not wasting my time!

The only (optional) step I had to take was to switch my desktop background to the new artwork. (There are extra laughlin-backgrounds-* packages that include a number of striking photographs and alternate artwork, including an animated background that changes to reflect the time of day.) I also think this picture and this picture, both by Design team superstar Emily Dirsh, are beautiful alternatives.

This is the third time I’ve used preupgrade for an upgrade to the next Fedora release on a home system. From everything I’ve seen, it’s a great way to proceed if you don’t want to install from scratch and reconfigure lots of stuff. It’s exceptionally helpful in cases where you have a non-optimal setup that you don’t want to mess with, for example not having a separate /home partition, where otherwise you’d need to have a backup and restore process bracketing your installation.** Preupgrade is simple enough that almost anyone should be able to use it, just by clicking through simple prompts.

---

* The default for Fedora installations now is to use 500 MB for /boot — though it used to be much less. If you have less, you may want to consider doing a full backup, reinstalling (and choosing at least 500 MB for this partition), and then restoring your data. That way in the future you can use preupgrade.

** Note that frequent backups are still absolutely vital though, no matter what you run or how you upgrade.

Update: Changed the title of the post, which I can’t explain other than my not thinking clearly. Wrong idiom! Bad writer, no cookie!

This week in fast forward.

I flew up to Red Hat’s office in Westford for the week to accomplish quite a large number of things, mainly a metric ton of meetings with my manager and a few other people around the department in relation to my new role at Red Hat. Therefore my schedule’s going to keep me quite out of touch throughout the week. Of course my email will work and I’ll be online quite a bit, but my appearances will be somewhat of the “jump on, jump off” variety.

I feel a little ashamed this is my first blog post in over a week — especially given the subject matter in my last post. Last week went by so fast my head was spinning by the end of it. (Fortunately that stopped before I went to skating lessons on Saturday morning.) I’ll try to write something substantive tomorrow, especially regarding some cool stuff we’ve been doing with Fedora Insight. I bought a bunch of Drupal books and have been trying to study up on this very cool framework, although this week will really put a crimp in my progress.

I did get to hunker down over a little work on the plane, and thanks to git I was able to contribute some work to the Websites team, and help them make the new website even more translatable by our translator teams around the world. Nice to be able to accomplish something that helps other people while I’m stuck in a flying metal tube!

Communicate more, not less.

A couple unrelated comments and discussions I saw over the past few days prompted me to write about how the open source way should affect conversations in Fedora. Our modus operandi in Fedora is “default to open.” It keeps us accountable to each other, honest in our assessments, and (hopefully) constructive in our relations with each other.

Most importantly, though, open communication lets others know what we’re thinking and doing, and gives everyone a chance to participate and assist. Without open conversation, it’s infinitely harder to tell what people are up to in Fedora, or any open source work. Sure, you could watch myriad commit lists or RSS feeds, but the trouble with that is there’s no human context around it. And often those automated messages can be confusing or surprising unless someone’s established a prior context around them. The cornerstone of collaboration is communication, and the success of open source depends on collaboration.

Here are some of the opportunities I’ve sometimes observed in open source efforts (not just Fedora) to encourage positive growth toward openness. Sometimes I run into these opportunities personally, and regularly remind myself that increasing communication (rather than simply work output) can often be the best answer.

Do you feel like a lot of work is hanging on you personally? Nothing contributes to burnout quite like when you feel you’re a single point of failure. Making your work more open forces you to confront areas where you’re having trouble, and to ask for help. You can’t be a force for positive change unless you embrace the fact that you can’t do everything yourself. Lydia Pintscher hosted a wonderful article by Asheesh Laroia the other day about how Fedora Design team lead Máirín Duffy avoids this problem by effectively turning “to do” items into open calls to action for the community.

At times it may take more time to tell people about the work than it would to do it. But explaining and documenting are, more often than not, the key to spreading knowledge of, and participation in, an activity. Yes, it is possible no one will help even after you explain and document how to do something. But it’s certain no one will help if you don’t. Building an architecture of participation is to create opportunities for others.

Do you see an area that’s not getting enough attention in your team, even though it’s assigned to someone? The best answer isn’t necessarily to cajole that person, even if you feel like they’re responsible for it. Sometimes the best thing you can do for them is to ask for help on their behalf. There are numerous outlets where you can call out for help: (1) write a blog post that’s carried on one or more aggregators (like Planet Fedora), (2) send status messages on social networking using identifying hash tags about your subject, or (3) make contact with other open source groups outside your project that work on related material, to see if someone’s interested in helping.

Real life happens to all volunteers, and it’s not always possible for them to cover all their responsibilities — volunteer activities frequently take a backseat when available time shrinks, whatever the reason. In Fedora, our teammates are our friends, and we do what we can to make them and our team successful. That might mean helping them find someone to take over for them, if they’re too swamped to follow through.

If you see this happening as a pattern on a team, perhaps it’s worthwhile to examine the scope of the work you’re doing. Do you have enough people to cover it? Consider contracting efforts around a smaller target for a time, while you look for new contributors who are interested in participating. Doing a few things well can be much more rewarding for the team than leaving lots of things incomplete or finishing lots of tasks in a less satisfactory way. (This is also true in the scope of a single contributor — each of us can likely get more satisfaction and pride out of a few jobs well done, rather than many jobs not so well done.)

Are you having substantial conversations privately where the community can’t participate? You could unknowingly be sapping energy from your own team! Remember, one of the reasons we’re involved in free and open source software is that more eyeballs, heads, and hands are inevitably better than a few. Agree on the problem you’re trying to solve first, so you can have a productive conversation about how to solve it. Then make sure you have that conversation in a mailing list, where everyone can see it’s going on, and offer input and assistance.

Community maven/wunderkind Mel Chua has frequently written, “If it didn’t happen on the list, it didn’t happen.” More and more I’ve come to appreciate that wisdom, because frequently the biggest frustrations, confusions, and misunderstandings arise simply because people don’t know what their teammates are thinking or doing. The more open we are in our communications, the less likely we’ll cause those types of problems. Of course, open communication doesn’t equal “no arguments.” But you can choose to have an argument purely about the merits of different types of solutions, rather than arguing about that, plus conflicts over perceived slights, plus issues of hidden agendas, plus… Get the picture?*

Do you feel the need to encourage teammates toward positive transparency? You can help others be transparent by simply asking non-loaded questions in a public forum. Make it clear you’re supportive of their work, and that you’d like to know more about it so you help either by participating, or encouraging others to participate. You don’t even need to mention transparency, since it’s implicit in your public question. In fact, doing so can often be detrimental, with the exact opposite effect of what you intended. If someone communicates with you privately, let them know you’d like to share that with the community, and if it meets with approval, do so promptly and fully. It usually only takes a couple of minor, non-judgmental efforts to help teammates understand the value of “default to open,” so everyone can benefit.

Many times, I find people aren’t transparent simply because they’re tentative. No one wants to be publicly embarrassed, after all! This is why it’s so important to nurture a culture of positivity and constructive behavior in an open source team or project. No one should be afraid to speak up for fear they’re wrong. Being wrong is an opportunity to learn, and not just for the people involved in the conversation. The opportunity also exists for those reading along on the list, or who come across the conversation later thanks to a search engine. Encouraging people toward transparency requires both halves of this strategy to be effective — you can’t simply make requests unless people feel they (not just their open communications) are welcome.

Anyway, these are just some idle thoughts I was having today while exercising and thinking about open communication. I’d love to hear trackbacks and comments from people about their personal experiences and approaches with communicating more openly and transparently, especially specific experiences and how it improved the outcome.

---

* Admittedly, it’s much easier to defuse those problems later if everyone assumes good intentions, but in my experience, most forms of electronic communication make that quite difficult. But that’s a behavior we can all still aim to practice every day!