Posts Tagged ‘Lucid’
Navigating the PolicyKit maze
I’ve written a simple application which will automatically extract media from CDs and DVDs when they are inserted into the drive attached to my server. This makes it easy for me to compile all of my media in one place and access it anytime I like. The application uses the modern udisks API, formerly known as DeviceKit-disks, and I wrote it in part to learn get some experience working with udisks (which, it turns out, is rather nice indeed).
Naturally, I wanted to grant this application the privileges necessary to mount, unmount and eject removable media. The server is headless, and the application runs as a daemon, so this would require explicit configuration. udisks uses PolicyKit for authorization, so I expected this to be very simple to do. In fact, it is very simple, but finding out exactly how to do it wasn’t quite so easy.
The Internet is full of web pages which recommend editing /etc/PolicyKit/PolicyKit.conf. As far as I can tell, nothing pays attention to this file anymore, and all of these instructions have been rendered meaningless. My system was also full of tools like polkit-auth, from the apparently-obsolete policykit package, which kept their configuration in some other ignored place, i.e. /var/lib/PolicyKit. It seems the configuration system has been through a revolution or two recently.
In Ubuntu 10.04, the right place to configure these things seems to be /var/lib/polkit-1/localauthority, and this is documented in pklocalauthority(8). Authorization can be tested using pkcheck(1), and the default policy can be examined using pkaction(1).
I solved my problem by creating a file in /var/lib/polkit-1/localauthority/50-local.d with a .pkla extension with the following contents:
[Access to removable media for the media group] Identity=unix-group:media Action=org.freedesktop.udisks.drive-eject;org.freedesktop.udisks.filesystem-mount ResultAny=yes
This took effect immediately and did exactly what I needed. I lost quite some time trying to figure out why the other methods weren’t working, so perhaps this post will save the next person a bit of time. It may also inspire some gratitude for the infrastructure which makes all of this work automatically for more typical usage scenarios, so that most people don’t need to worry about any of this.
Along the way, I whipped up a patch to add a --eject option to the handy udisks(1) tool, which made it easier for me to test along the way.
Rethinking the Ubuntu Developer Summit
This is a repost from the ubuntu-devel mailing list, where there is probably some discussion happening by now.
After each UDS, the organizers evaluate the event and consider how it could be further improved in the future. As a result of this process, the format of UDS has evolved considerably, as it has grown from a smallish informal gathering to a highly structured matrix of hundreds of 45-to-60-minute sessions with sophisticated audiovisual facilities.
If you participated in UDS 10.10 (locally or online), you have hopefully already completed the online survey, which is an important part of this evaluation process.
A survey can’t tell the whole story, though, so I would also like to start a more free-form discussion here among Ubuntu developers as well. I have some thoughts I’d like to share, and I’m interested in your perspectives as well.
Purpose
The core purpose of UDS has always been to help Ubuntu developers to explore, refine and share their plans for the subsequent release. It has expanded over the years to include all kinds of contributors, not only developers, but the principle remains the same.
We arrive at UDS with goals, desires and ideas, and leave with a plan of action which guides our work for the rest of the cycle.
The status quo
UDS looks like this:
This screenshot is only 1600×1200, so there are another 5 columns off the right edge of the screen for a total of 18 rooms. With 7 time slots per day over 5 days, there are over 500 blocks in the schedule grid. 9 tracks are scattered over the grid. We produce hundreds of blueprints representing projects we would like to work on.
It is an impressive achievement to pull this event together every six months, and the organizers work very hard at it. We accomplish a great deal at every UDS, and should feel good about that. We must also constantly evaluate how well it is working, and make adjustments to accommodate growth and change in the project.
How did we get here?
(this is all from memory, but it should be sufficiently accurate to have this discussion)
In the beginning, before it was even called UDS, we worked from a rough agenda, adding items as they came up, and ticking them off as we finished talking about them. Ad hoc methods worked pretty well at this scale.
As the event grew, and we held more and more discussions in parallel, it was hard to keep track of who was where, and we started to run into contention. Ubuntu and Launchpad were planning their upcoming work together at the same time. One group would be discussing topic A, and find that they needed the participation of person X, who was already involved in another discussion on topic B. The A group would either block, or go ahead without the benefit of person X, neither of which was seen to be very effective. By the end of the week, everyone was mentally and physically exhausted, and many were ill.
As a result, we decided to adopt a schedule grid, and ensure that nobody was expected to be in two places at once. Our productivity depended on getting precisely the right people face to face to tackle the technical challenges we faced. This meant deciding in advance who should be present in each session, and laying out the schedule to satisfy these constraints. New sessions were being added all the time, so the UDS organizers would stay up late at night during the event, creating the schedule grid for the next day. In the morning, over breakfast, everyone would tell them about errors, and request revisions to the schedule. Revisions to the schedule were painful, because we had to re-check all of the constraints by hand.
So, in the geek spirit, we developed a program which would read in the constraints and generate an error-free schedule. The UDS organizers ran this at the end of each day during the event, checked it over, and posted it. In the morning, over breakfast, everyone would tell them about constraints they hadn’t been aware of, and request revisions to the schedule. Revisions to the schedule were painful, because a single changed constraint would completely rearrange the schedule. People found themselves running all over the place to different rooms throughout the day, as they were scheduled into many different meetings back-to-back.
At around this point, UDS had become too big, and had too many constraints, to plan on the fly (unconference style). We resolved to plan more in advance, and agree on the scheduling constraints ahead of time. We divided the event into tracks, and placed each track in its own room. Most participants could stay in one place throughout the day, taking part in a series of related meetings except where they were specifically needed in an adjacent track. We created the schedule through a combination of manual and automatic methods, so that scheduling constraints could be checked quickly, but a human could decide how to resolve conflicts. There was time to review the schedule before the start of the event, to identify and fix problems. Revisions to the schedule during the event were fewer and less painful. We added keynote presentations, to provide opportunities to communicate important information to everyone, and ease back into meetings after lunch. Everyone was still exhausted and/or ill, and tiredness took its toll on the quality of discussion, particularly toward the end of the week.
Concerns were raised that people weren’t participating enough, and might stay on in the same room passively when they might be better able to contribute to a different session happening elsewhere. As a result, the schedule was randomly rearranged so that related sessions would not be held in the same room, and everyone would get up and move at the end of each hour.
This brings us roughly to where things stand today.
Problems with the status quo
- UDS is big and complex. Creating and maintaining the schedule is a lot of work in itself, and this large format requires a large venue, which in turn requires more planning and logistical work (not to mention cost). This is only worthwhile if we get proportionally more benefit out of the event itself.
- UDS produces many more blueprints than we need for a cycle. While some of these represent an explicit decision not to pursue a project, most of them are set aside simply because we can’t fit them in. We have the capacity to implement over 100 blueprints per cycle, but we have *thousands* of blueprints registered today. We finished less than half of the blueprints we registered for 10.04. This means that we’re spending a lot of time at UDS talking about things which can’t get done that cycle (and may never get done).
- UDS is (still) exhausting. While we should work hard, and a level of intensity helps to energize us, I think it’s a bit too much. Sessions later in the week are substantially more sluggish than early on, and don’t get the full benefit of the minds we’ve brought together. I believe that such an intense format does not suit the type of work being done at the event, which should be more creative and energetic.
- The format of UDS is optimized for short discussions (as many as we can fit into the grid). This is good for many technical decisions, but does not lend itself as well to generating new ideas, deeply exploring a topic, building broad consensus or tackling “big picture” issues facing the project. These deeper problems sometimes require more time. They also benefit tremendously from face-to-face interaction, so UDS is our best opportunity to work on them, and we should take advantage of it.
- UDS sessions aim for the minimum level of participation necessary, so that we can carry on many sessions in parallel: we ask, “who do we need in order to discuss this topic?” This is appropriate for many meetings. However, some would benefit greatly from broader participation, especially from multiple teams. We don’t always know in advance where a transformative idea will come from, and having more points of view represented would be valuable for many UDS topics.
- UDS only happens once per cycle, but design and planning need to continue throughout the cycle. We can’t design everything up front, and there is a lot of information we don’t have at the beginning. We should aim to use our time at UDS to greatest effect, but also make time to continue this work during the development cycle. “design a little, build a little, test a little, fly a little”
Proposals
- Concentrate on the projects we can complete in the upcoming cycle. If we aren’t going to have time to implement something until the next cycle, the blueprint can usually be deferred to the next cycle as well. By producing only moderately more blueprints than we need, we can reduce the complexity of the event, avoid waste, prepare better, and put most of our energy into the blueprints we intend to use in the near future.
- Group related sessions into clusters, and work on them together, with a similar group of people. By switching context less often, we can more easily stay engaged, get less fatigued, and make meaningful connections between related topics.
- Organize for cross-team participation, rather than dividing teams into tracks. A given session may relate to a Desktop Edition feature, but depends on contributions from more than just the Desktop Team. There is a lot of design going on at UDS outside of the “Design” track. By working together to achieve common goals, we can more easily anticipate problems, benefit from diverse points of view, and help each other more throughout the cycle.
- Build in opportunities to work on deeper problems, during longer blocks of time. As a platform, Ubuntu exists within a complex ecosystem, and we need to spend time together understanding where we are and where we are going. As a project, we have grown rapidly, and need to regularly evaluate how we are working and how we can improve. This means considering more than just blueprints, and sometimes taking more than an hour to cover a topic.
Lucid ruminations
A few months ago, I wrote about changes in our development process for Ubuntu 10.04 LTS in order to meet our goals for this long-term release. So, how has it turned out?
Well, the development teams are still very busy preparing for the upcoming release, so there hasn’t been too much time for retrospection yet. Here are some of my initial thoughts, though.
- Merge from Debian testing – Martin Pitt has started a discussion on ubuntu-devel about how this went. For my part, I found that Lucid included fewer surprises than Karmic.
- Add fewer features – This is difficult to evaluate objectively, but my gut feeling is that we kept this largely under control. As usual, a few surprise desktop features were implemented that not everyone is happy about, myself included.
- Avoid major infrastructure changes – I think we did reasonably well here, though Plymouth is a notable exception. It resulted (unsurprisingly) in some nasty bugs which we’ve had to spend time dealing with.
- Extend beta testing – This will be difficult to assess, though if 10.04 beta was at least as good as 9.10 or 9.04 beta, then it will have arguably been a success.
- Freeze with Debian – Although early indications were good, this didn’t work out so well, as Debian’s freeze was delayed
- Visualize progress – The feature status page provided a lot of visual progress information, and the system behind it allowed us to keep track of work slippage throughout the cycle, both of which seemed like a firm step in the right direction. I’m looking forward to hearing from development teams how this information helped them (or not).
A more complete set of retrospectives on Lucid should give us some good ideas for how to improve further in Maverick and beyond.
Update: Fixed broken link.
Interviewed by Ubuntu Turkey
As part of my recent Istanbul visit, I was interviewed by Ubuntu Turkey. They’ve now published the interview in Turkish. With their permission, the original English interview has been published on Ubuntu User by Amber Graner.
Ubuntu Inside Out – Free Software and Linux Days 2010 in Istanbul
In early April, I visited Istanbul to give a keynote at the Free Software and Linux Days event. This was an interesting challenge, because this was my first visit to Turkey, and my first experience presenting with simultaneous translation.
In my new talk, Ubuntu Inside Out, I spoke about:
- What Ubuntu is about, and where it came from
- Some of the challenges we face as a growing project with a large community
- Some ways in which we’re addressing those challenges
- How to get involved in Ubuntu and help
- What’s coming next in Ubuntu
The organizers have made a video available if you’d like to watch it (WordPress.com won’t let me embed it here).
Afterward, Calyx and I wandered around Istanbul, with the help of our student guide, Oğuzhan. We don’t speak any Turkish, apart from a few vocabulary words I learned on the way to Turkey, so we were glad to have his help as we visited restaurants, cafes and shops, and wandered through various neighborhoods. We enjoyed a variety of delicious food, and the unexpected company of many friendly stray cats.
It was only a brief visit, but I was grateful for the opportunity to meet the local free software community and to see some of the city.
Ubuntu 10.04 LTS: How we get there
The development of Ubuntu 10.04 has been underway for nearly two months now, and will produce our third long-term (LTS) release in April. Rick Spencer, desktop engineering manager, summarized what’s ahead for the desktop team, and a similar update will be coming soon from Jos Boumans, our new engineering manager for the server team.
What I want to talk about, though, is not the individual projects we’re working on. I want to explain how the whole thing comes together, and what’s happening behind the scenes to make 10.04 LTS different from other Ubuntu releases.
Changing the focus
Robbie Williamson, engineering manager for the foundations team, has captured the big picture in the LTS release plan, the key elements of which are:
Merge from Debian testing
By merging from Debian testing, rather than the usual unstable, we aim to avoid regressions early in the release cycle which tend to block development work. So far, Lucid has been surprisingly usable in its first weeks, compared to previous Ubuntu releases.
Add fewer features
By starting fewer development projects, and opting for more testing projects over feature projects, we will free more time and energy for stabilization. This approach will help us to discover regressions earlier, and to fix them earlier as well. This doesn’t mean that Ubuntu 10.04 won’t have bugs (with hundreds of millions of lines of source code, there is no such thing as a bug-free system), but we believe it will help us to produce a system which is suitable for longer-term use by more risk-averse users.
Avoid major infrastructure changes
We will bring in less bleeding-edge code from upstream than usual, preferring to stay with more mature components. Where a major transition is brewing upstream, we will probably opt to defer it to the next Ubuntu cycle. While this might delay some new functionality slightly, we believe the additional stability is well worth it for an LTS release.
Extend beta testing
With less breakage early in the cycle, we plan to enter beta early. Traditionally, the beta period is when we receive the most user feedback, so we want to make the most of it. We’ll deliver a usable, beta-quality system substantially earlier than in 9.10, and our more adventurous users will be able to upgrade at that point with a reasonable expectation of stability.
Freeze with Debian
With Debian “squeeze” expected to freeze in March, Ubuntu and Debian will be stabilizing on similar timelines. This means that Debian and Ubuntu developers will be attacking the same bugs at the same time, creating more opportunities to join forces.
Staying on course
In addition, we’re rolling out some new tools and techniques to track our development work, which were pioneered by the desktop team in Ubuntu 9.10. We believe this will help us to stay on course, and make adjustments earlier when needed. Taking some pages from the Agile software development playbook, we’ll be planning in smaller increments and tracking our progress using burn-down charts. 
As always, we aim to make Ubuntu development as transparent as possible, so all of this information is posted publicly so that everyone can see how we’re doing.
Delivering for users
By making these changes, we aim to deliver for our users the right balance of stability and features that they expect from an Ubuntu LTS release. In particular, we want folks to feel confident deploying Ubuntu 10.04 in settings where it will be actively maintained for a period of years.
Who’s afraid of Ubuntu Women?
At the recent Ubuntu Developer Summit, there were three sessions held to discuss the future of the Ubuntu Women project. Unfortunately, I was unable to attend the first two, because I didn’t realize the first one was happening, and I had a scheduling conflict for the second. The first session was video recorded, and hopefully the recording will be made available soon. While attending the third and final session, I tried to catch up on the earlier discussion as I listened to what was being said.
The first thing I noticed in the Gobby notes was a link to an existing roadmap for Ubuntu Women. I hadn’t seen that document before, and was encouraged to see that it included concrete, measurable goals for increasing the participation of women in Ubuntu. In particular, it presents a goal of increased representation in Ubuntu governing bodies, which I think is an important step in promoting gender diversity in the project. People want leaders they can identify with.
The next thing I found in the document was a list of goals. I asked about the relationship between the goals in Gobby and the ones in the wiki roadmap, and someone explained that the goals in the wiki were long term, while the ones in Gobby were short term (to be completed in the 6-month Lucid cycle).
There were about 25 people attending the session, and most of the talking was done by Amber Graner, Elizabeth Krumbach, Laura Czajkowski, Jono Bacon and Kurt von Finck. It was Friday afternoon, the last day of an intense week, and the energy level was fairly low. The focus seemed to be on reviewing the group’s objectives and agreeing who would take the next steps. The objectives were as follows:
Clarify the purpose of the #ubuntu-women channel
The group seemed to feel that there was confusion about what this IRC channel was for. A couple of men in the room said that they didn’t know whether they could or should join the channel, because it had the word “women” in the name.
The core of the issue seemed to be less about purpose than governance. The group was concerned about the fact that the channel was not publicly logged like most other Ubuntu channels, and that this gave the impression of it being a “fiefdom” within the community, or a place where people would “gossip”.
As far as I’m aware, there is at present no requirement that Ubuntu channels (official or unofficial) must be publicly logged, and there are many channels which are not. If this is considered to be a requirement for a healthy IRC community, then the Ubuntu IRC council would be in a good position to put forward such a policy. I don’t think I have enough experience in regulating IRC discussions to say whether this is the right thing to do, but it seemed a bit odd to me that this came up in the context of #ubuntu-women. It isn’t clear to me what problem this is meant to solve, and whether it is consistent with precedent (again, I’m not very familiar with IRC governance).
There was some confusion over why folks might not want the channel to be logged. Kurt suggested that if the conversation adhered to the Code of Conduct, there should be no reason not to publish it. I suggested that there were many occasions where a conversation might be appropriate to keep “off the record” while still following the code of conduct, and that these were separate issues (standards of behavior versus privacy).
The group’s agreed actions on this topic included agreeing and documenting guidelines for behavior in #ubuntu-women, and arranging for the conversations in the channel to be publicly recorded.
Create a safe space IRC channel
This objective seemed to acknowledge that something would be lost if the conversations in #ubuntu-women were made a matter of public record. The group therefore proposed the creation of a separate channel, which would still be logged, but only the Community Council would have access to the logs.
The reason for this seemed to be, again, the need to ensure regulation, and the concern that without oversight, channel participants would misbehave. While a safe space does require oversight in order to be maintained, the goal of involving the CC seemed to be general governance of behavior rather than the safety of women. The group seemed to acknowledge that this idea needed more work, and in particular wasn’t satisfied with the terminology of safe space.
The agreed actions were to create the new channel, document guidelines for behavior in it, and arrange for the conversation there to be logged for the Community Council.
Appoint a leader of the Ubuntu Women team
The group seemed to feel that, in order for the team to meet its goals, it was important to implement some form of government, and that the appropriate structure (at least initially) would be to have a single leader. They proposed to define the responsibilities of such a role, solicit nominations from the community, and ask the Community Council to appoint a leader.
I asked why the team could not appoint their own leader, and they explained that the team was not well defined enough, e.g. the Launchpad team is open for anyone to join. Without explicit membership, it’s difficult to organize a fair election. They suggested that the appointed leader would go about organizing the team to the point where it could govern itself more effectively.
There seemed to be some concern that this would be controversial.
Change the perception of Ubuntu Women
After the written goals had been reviewed, Amber said that in her view, the true value of the sessions had been to change the perception of Ubuntu Women in the community, and that the perception had been very negative. All of the vocal participants agreed with this assessment, seemed to feel this was an important problem to solve, and felt that great progress had been made during the course of UDS.
I was surprised by this, because I hadn’t encountered this perception myself, and so I asked to hear more about it. Several people asserted that that there was a problem, that Ubuntu Women and/or its IRC channel were perceived in a negative light. Two men in the room offered anecdotes: one didn’t think he should join the IRC channel because it had “women” in the name (which seems like a different issue), and another said that someone in his LoCo had advised him to avoid it because it was hostile.
I didn’t really understand all of this, but I didn’t want to derail the conversation, particularly as I had missed the first two thirds of it. In talking to people following the event, the issue at hand seems to be the IRC channel, #ubuntu-women, rather than Ubuntu Women itself. The channel, at one point, had become a sort of common meeting place for women in various geek communities, and was a place where they would sometimes blow off steam, or conduct broader feminist discussions beyond the scope of Ubuntu Women. This was apparently a bit off-putting to the uninitiated, as well as to some of the channel’s regular participants.
Some time ago, #ubuntu-women reverted back to its original purpose and the other discussion moved elsewhere, but it seems that this perception remained among some members of the Ubuntu community. This also may explain why I’ve been hearing that people are confused about the difference between Geek Feminism and Ubuntu Women, because some of the same people are involved in both, and discussed both on #ubuntu-women.
Hopefully that’s the end of this apparent stigma, and Ubuntu Women can get on with the business of helping the Ubuntu community to welcome more women.
Ubuntu Developer Summit: 10.04 (Lucid)
This week, I’m in Dallas, Texas working at the Ubuntu Developer Summit. Hundreds of Ubuntu developers and other community members are gathered to discuss the future of the project, particularly the 10.04 release. Developers are engaged in technical discussions about how to implement new features for the release next April.
Obviously, a week is not enough time to decide, design and plan half a year of work, but we try to fit as much as possible into the week, because it is such a rare opportunity for us to work together face to face. In order to make the best use of our time, there is a very full schedule of sessions, and we do a great deal of advance preparation.
There is a persistent rumor that UDS is where we decide what to do in the next cycle, but this isn’t quite accurate. UDS is where we primarily figure out how to do what needs to be done. Naturally, UDS is a sea of ideas, thanks to all of the creative thinking which happens among attendees, and we do dream up and decide to do new things there. However, most of this is determined well before we all board airplanes to travel to UDS.
Brainstorm is constantly collecting and ranking suggestions from Ubuntu users. Ubuntu development teams hold public meetings on IRC where they discuss ideas and plans. Canonical stakeholders submit requirements for their needs. All of this information is aggregated, sorted, evaluated and prioritized, largely by the heroic engineering managers at Canonical, who then develop the core of the agenda for UDS. Additional sessions are then added as they come up during the week, when there is space.
At this particular UDS, I am moderating the server track, where we’re hashing out the details of our projects for Ubuntu Server Edition 10.04. Being a UDS track moderator makes for a very busy week, with back-to-back sessions all day for five days straight. It’s only Wednesday, and I’m feeling a bit fried already, having been away from home for over two weeks.
In each session, there is a discussion between the developers working on the project, the other UDS attendees who are interested in it, and any random folk who listen in on the audio stream and add questions or comments via IRC. The participants take notes using Gobby and then publish them in the Ubuntu wiki, where they are developed into specification documents tracked in Launchpad.
Those specifications are further broken down into work items, which we can use to maintain a burn down chart. Rick Spencer, our desktop engineering manager, gave a presentation this afternoon about how that process will work. The burn down chart will give us a tool for establishing whether we are on track to complete our work, or if we are under or over committed, and make adjustments to our plans as needed.
I have a sense of tremendous momentum going into this release cycle, which will culminate in our third LTS (long-term support) release of Ubuntu.
We'll see | Matt Zimmerman 