Posts that are soas-ish
With yet another (Fedora and SoaS) release cycle coming up, one of the things we can do to prepare for the future is to look at the past and try to learn from both the intentional and inadvertent things we’ve done before. With that in mind, the Sugar on a Stick team has put together a release history for v.3 Mirabelle, recapping the main decisions/events and rationale of the past 6 months.
Sugar Labs folks interested in a peek behind the scenes may find it fascinating reading, but we think Fedora folks curious about what the spins process looks like from the “other side” and Teaching Open Source folks looking for examples of reflective learning may also benefit from a quick skim. We had many triumphs and learned many lessons (often the hard way) – some excerpts are below.
On becoming a Fedora Spin
Before SoaS was a spin, it was a Fedora Remix – which means that bit-wise, the product looked the same, but the technical work that needed to happen to generate it was all done manually and without external resources and support, so it happened spasmodically and slowly and with a great number of sleepless nights.
Becoming a Fedora Spin gave us access to Fedora’s engineering, marketing, and QA resources, which dramatically improved the sustainability and scaleability of our release engineering processes. For instance, .iso files stopped being produced by the “Sebastian manually builds them every time” process, and started being automatically generated for testing by Fedora build servers. We gained some instant automation of the infrastructure we need anyway, without any more work or maintenance on our part, so we could focus on things like… making Activities work, the stuff that’s actually unique to Sugar.
The January 8, 2010 SoaS planning meeting led to the decision to apply for spin status. Looking at the January mailing list archives, we didn’t explain the significance of the spin decision very well then, which may have led to communication disconnects down the line that made Activity development and Marketing more difficult. In particular, we did not make it clear enough that we were now tied to the Fedora release cycle, and what that meant.
On accidentally making life difficult for Activity developers
Two of our upstreams (Fedora and ASLO) basically collided when they combined, and didn’t realize that collision was coming, because we didn’t track dependencies between them… part of the problem was that we didn’t know who was responsible for keeping track of that aspect of communication, so everyone assumed it was someone else and nobody did it.
The Activities confusion manifests itself in the small number of “supported” activities in the v3 release. Marketing was then confronted with the sudden removal/noninclusion of activities from the release – again, this is something that could have been prevented with a working feature process.
Major accomplishments this release cycle
- We have a team!
- We have a release schedule!
- We started using the Fedora Spins process and engineering resources, which made release engineering much smoother.
- We started driving communications to public channels – notably the SoaS mailing list – so things are more transparent.
- Multiple people have commit access to each repository that needs to be handled, so there are no single-person bottlenecks remaining.
- We shifted to a time-based release cycle, meaning we had a target release date set early in the process rather than our prior “it seems ready… now-ish?” method.
There’s more available at the full recap – we’re still a pretty fledgling project and new to introducing many of these processes (and still building our scaffolding!) so if you have thoughts/comments/suggestions/advice on how we could improve, please let us know via comments here, the soas mailing list, or pinging pbrobinson (Peter), sdziallas (Sebastian), or mchua (Mel) on IRC (we’re often in #sugar on irc.freenode.net).
Planning for the 4th release (the codename for this release is yet to
be chosen – suggestions for this welcome, too!) begins on Monday, June
7, at our weekly IRC meeting. And of course, if you’re interested in helping with the next release, please join us!
I just sent this email to the Sugar on a Stick mailing list and am too tired to make it sound less like an email and more like a blog post, yet thought people should read it and see what we’re up to in preparation for the impending Tuesday release of this Fedora spin.
With the impending Tuesday release of SoaS v.3 Mirabelle, and one of the goals of the release to make the project more sustainable (in part by making it easier for new contributors to get involved), we figured that a contributor portal would be a good idea.
Behold the draft: http://wiki.sugarlabs.org/go/Sugar_on_a_Stick_Pagerevision (with many photo thanks to Mike Lee!)
The idea is that http://spins.fedoraproject.org/soas/ will be the main “shiny” user page for those who simply want to learn about the
project, download the image, and use it – and that the wiki page at http://wiki.sugarlabs.org/go/Sugar_on_a_Stick will be replaced by this
page revision at the end of tomorrow (Monday) and serve as the main contributors portal, with the two referring to each other.
You may notice that four stubs remain:
Pointers to resources and/or help filling these out is super-welcome, as is feedback on the idea as a whole. I’ll be looking at feedback and
making the merge when I’m out work tomorrow night; we can of course make edits after that (it is a wiki, after all) but it would be nice
to have something shiny-looking and shippable when the release goes out.
PS: As a reminder, we have our SoaS v.3 “how did we do?” review meeting on Tuesday, June 1st, in #sugar-meeting at 1900 UTC.
To the anonymous editor (wiki username “Interested”) who transformed the instructions for making and using Sugar on a Stick instructions for Mac users from a stub-tastic fragment of a page to an eloquent manual of glory – thank you! This was a wonderful surprise, especially as we launch into the documentation-and-supporting-resources part of the release cycle now that the SoaS image itself has been change-frozen.
Any Mac denizens around who can test out these instructions and see:
- If they make sense? (Is this a helpful writing style for guides for our teacher/parent/student/non-developer audience, and should we replicate it elsewhere?)
- If they work? (Do the instructions, if followed, actually produce a working system?)
 In English, this means “the technical work and the product itself is basically finished according to the Fedora 13 release schedule, so we’re winding down on that and working on supporting materials now.”
Experiment after a conversation with Bernie: The dev-love keyword, which is a tag for fixes that make the lives of developers easier when applied. These are the tickets with force-multiplying effects and we should tackle those whenever possible – even, I’d argue, over features other than the most critical-path ones (i.e. “does Sugar still work?”) It’s all about capacity-building.
Now, this keyword is going to die unless it’s documented somewhere, and people adopt it – so here’s what I’m asking.
If you’re a Sugar developer – either Activities or sugar-core – what features, bugfixes, tools, or code hacks would make your life easier? I’m not talking about cool features you’d like to see in Sugar for end-users or what would make it easier for kids (or others) to do Sugar development, although all these things may certainly overlap. I’m asking for things we can do to your Sugar hacking experience a better one. Ticket numbers and links are preferred, but I’ll take task descriptions and file/tag them myself if I have to.
What would make your Sugar hacking easier and more fun?
It’s less than 3 weeks to the F13 release, and therefore high time we started doing some consistent QA for Sugar on a Stick – which, for the uninitiated, is a Fedora Spin based on the Sugar Learning Platform. Here’s the status as of the April 29, 2010 compose (which is identical to the current May 1st nightly build) for the main build and each of the Activities that ships by default.
|| Turtle Art
|| yes, but no book files to open
What do these results mean, and how can they be reproduced? More details on the Mirabelle page. Basically, this is the most minimal of smoke tests; I’m not going to pretend that this is good work, but it’s something that needs to happen, and the sort of thing where something is better than nothing. The goal was to come up with a way to verify, in under 1 hour total (from “start downloading image” to “finish reporting test results”), that a SoaS image and the Activities therein are minimally functional – they boot, they run, they do something, they shut down cleanly, and they save their results to the Journal.
The current smoke tests take me less than 25 minutes to execute from start to finish, so if we assume that the image can be downloaded and burned (I used liveusb-creator on my Fedora 12 system) in 30 minutes and results can be reported to the wiki table in roughly 5 – which matches with my timing (and I made that wiki page from scratch for the first round, too), we’re set, and so I’ve closed a long-standing bug asking for SoaS test cases. For now.
The test page is linked to from the main getting-involved page, which needs a lot of cleanup. We’ll probably hook the (under construction – anyone want to help make banners?) SoaS Fedora Spin website to openhatch when going through things with the mop n’ bucket (although at this point I’m feeling more like breaking out a weed-whacker).
How can you help?
In terms of running the tests for the upcoming v.3.0 (F13-based) Mirabelle release, we’re actually set. If this takes me less than an hour a day, I can do that for 15 out of the 17 days remaining with no problem (exceptions made for May 8th and 9th, when I will be off camping for my birthday). We need to come up with a better way of doing this for v.4.0, so better test cases, test case/reporting management systems, and Activity criteria (read: tests, please) are extremely welcome – that’s all long-term, though.
In terms of getting Mirabelle ready to go out the door, right now we need:
- this telepathy-gabble update to be pushed to the Fedora updates repo – it has +3 karma but is still in testing, and must be pushed before Tuesday; without it, collaboration in SoaS does not work at all. (By the way, I started a howto for testing updates, which needs some help – writing instructions on how to consistently get a VM running is surprisingly difficult.)
- download/install instructions for burning the image to a stick, for every major operating system, that can be followed by a classroom teacher without technical expertise. We know the Blueberry install instructions do not fit this criteria, and would love for someone – probably a non-engineer – to help rewrite them.
- quotes, stories, screenshots, and photos (CC-BY, please) from Sugar/SoaS users on what they’ve done with the platform, cool things they’ve tried, how this fits into a classroom, and so forth, to be used on the spin webpage and related links – bonus points if you can talk about contributing to SoaS as well as using it!
More coming as we find out what we need. The spin page itself is under construction (along with a SOP on how to make spin pages – the process right now is probably more complex/painful than it should be) and screenshots are on their way. Stay tuned!
Question: what is the simplest possible ecosystem one could put together for a Sugar on a Stick (SoaS) pilot? I suspect it would consist of the following elements:
- An enthusiastic classroom teacher who “gets” Sugar and open source, is excited about integrating Sugar into her curriculum and having her students participate in the upstream Sugar Labs community, and is in constant contact with…
- …a local deployment support team with ties and familiarity with the Sugar Labs and Fedora communities and the ability to introduce the teacher and her students to them, hands-on troubleshooting experience, the ability to document events so that they make sense to both educators and engineers, and a quick QA feedback loop with…
- …SoaS developers with expertise in creating and customizing not just the SoaS software but the build and release engineering infrastructure needed to get it out the door on a regular and timely basis, who are aware of and responsive to the needs of the students and willing to adjust the software frequently and on-the-fly to make things work out for that classroom, and…
- …the small number of students in it, who all have their own SoaS stick (small number, 100% coverage) and are working to not just understand the open source community but to actively participate in it, with the blessing of…
- …school administrators and parents, who remain fully aware of what is going on at all times so that the learning can, when possible, extend into their homes (which all have computers) and beyond, and…
- …the hardware for the pilot itself chosen specifically for its compatibility with SoaS so everything will work out-of-the-box, with…
- …no funding/resource problems with all hardware purchased ahead of time, time volunteered, and a bit of discretionary budget for other needs that might crop up at…
- …a series of weekly deployment check-ins between developers and the support crew, between the support crew and the teacher and her students, between the deployment and support crew and the larger Sugar Labs community, between the teacher and the parents of her students, but only…
- …for a limited time, with the understanding by all parties that this is an experiment and that our biggest contribution to the Sugar Labs community is finding out whether it works or not, and demonstrating how and why – and of course,
- wonderful, supportive, informed upstream communities – in this case, Sugar Labs and Fedora (since SoaS is a Fedora Spin).
Which is exactly why the CFS pilot was set up the way it’s been set up. We’re not really working under realistic limitations – what we’re doing will largely not scale. But much of it will. And we’re trying to pull together the different components and show how they interrelate – by blogging, by slowly starting to find the right mailing lists to talk on, by experimenting with different ways we can all cope with data overload (for instance, Lynne May didn’t really start blogging until I put scribefire on her laptop – the tiny decrease in activation energy was enough).
Now if only we had a test case system. Note to self: stop being such a slacker in this department and get smw up already! If anyone would like to help me pick up on the smw-based test case management system project, let me know. It’s something I can easily mentor, but don’t have a lot of time to actually do myself.
I’m also having some trouble getting a good VM-based test setup going so I can quickly verify SoaS bugs being reported without having to get a spare stick, a spare laptop, boot things, etc… I’ll try again when the next nightly build comes out, and if that doesn’t work, will actually post a detailed trouble ticket. (Right now the chances that it might be the image’s fault rather than my setup’s fault are reasonably high.)
And Trac mail notifications have been… inconsistent, at best. Sometimes, when a ticket is created or commented on, and I own that ticket, I do not get email notices. It’s not my spam filters; I checked those first. Still trying to track this behavior and narrow it down so that it isn’t intermittent; I am not sure what triggers this (apparent) bug, or if there’s a way to see (on Trac’s end) whether it thinks it’s sending me an email each time.
Good things happening, always more things to fix – such is the nature of life, and the nature of satisfying work.
Colin Zwiebel has a nice description of the blog paper that Lynne May is using with her students. From the comments:
“…as people are introduced to tech tools, they have to deal with the issue of option overload. I think its a good exercise to learn that often you only care about a few key options.”
I’m hoping that the “blog paper” templates (and the “trac ticket” templates, too!) will be posted up under a CC-BY-SA license sometime soon – I’m pretty sure that’s the intent. They’re very simple. In the meantime, the students have begun to post, and have also started to get comments on their blogs – which is very exciting for them. I need to learn how to set up a Planet-like feed aggregator for the class (suggestions welcome – I’d like something a bit more recent that isn’t abandonware, as Planet itself hasn’t been touched for several years).
Without further ado, here are the kids, under their “Sugar Names.” If you read the comments, you’ll notice their parents are also getting into the act. ;-)
They’re still getting used to blogging and haven’t gotten to the point of submitting their first bug reports yet, but I’m told that a few have since been discovered, so perhaps tomorrow (the next “upstream day” – where the class circles around to think about what they have done with SoaS over the past week and figures out what and how they want to report back upstream) we will hear more.
The Record Activity wasn’t working in our (testing) image of SoaS. Fortunately, Sebastian was in town and quickly showed Melanie how to fix it – it’s just a matter of updating to the latest RPM.
- Switch to root.
- Run “yum update –enablerepo=rawhide sugar-record” (no quotes)
On a separate note, now that Melanie has picked up on deployment support (I have very little to do with that at this point other than being around for general minionhood – Melanie’s my boss for that) I’m starting to (finally) turn my thoughts to testing/QA infrastructure. The Welly crew has been keeping the flame alive and I’ve got quite a bit to learn from them from the year I’ve been out of the OLPC/Sugar QA loop.
This afternoon, Sebastian, Greg, and I called in remotely to Lynne May’s class, where they’re just starting their SoaS deployment. It was a short call – or rather, a short series of calls, because Lynne May first called Sebastian in Germany (with Greg and myself on IRC backchannel with him), then called me and Greg in Westford (with Sebastian on IRC backchannel), and everything – including technical glitches – took less than half an hour.
It was enough. On IRC, in the #sugar channel, debriefing afterwards…
Sebastian: They asked a lot of questions, like how I achieved this… having it on a stick, and why Sugar Labs was called Sugar Labs. They had bracelets or so attached to their usb keys to recognize them… and they sat down in a circle and showed them to me.
Mel: We saw the bracelets, but they were very much not in a circle at that point. We had a lot of kids running in front of the camera, coming up to the camera…
Sebastian: heh, ayup… constant movement ;-)
Mel: They asked us where we were and what time it was, and we said we were in Boston, in the office, at work, showed them the parking lot out the window, walked them through the hallways, they got to wave to Max. Spot was out, but we showed them his collection of penguins, frogs, and Star Wars action figures. (imitating excited kid:)”I LOVE Star wars action figures!”
Sebastian: LOL! :)
Mel: Loud enough for everyone in the office to hear through the headphones. And everyone within earshot started cracking up.
Sebastian: Yeah, so I showed them that it was late out here… Lynne May said I was going to bed “soon.” I replied that it depended on the definition of “soon”. ;-) We agreed to pretend it was soon.
Mel: “within the next 4 hours” == “soon”
Sebastian grins. yup!
Sebastian: I feel this is another kind of situation that reminds of… “why are we doing this?” As in, “ayup, THIS is why we’re doing it”
Mel: Oh, I wish I’d thought to take pictures of Greg talking with the kids from our side.
Sebastian: Mhm. Might have not been the last call. ;-)
We used Skype – I wish there were an open source option, but as things stand now, this is the best we were able to do. (And we still had connectivity issues.)
What we’re trying to do here is give the kids the idea that people they talk to online – people in the open source community they’re joining – are real people, people who may be far away in other places doing other things, but who also come online to work with them on Sugar. (This is a difficult abstract concept to grasp when you’re a first-grader. For that matter, it’s hard for grown-ups to grasp sometimes; I still have to explain how I work every day with people I’ve never met in person, and how yes, I really do know them, I don’t need to sit next to them all the time, etc.)
So we popped online – where they’ll usually see us – today. We’ll be dropping by the classroom in person briefly on Friday morning to go “look, we are real people!” And then I believe there will be regular short chat sessions on Friday mornings. (Yeah, more Skype. Better alternatives welcome.)
It’s hard to capture in words now; typing this seems so faded and gray compared to the rush of a posse of running, waving kids shouting into the screen, waving their USB sticks around, chorusing in overlapping voices (that I needed help understanding – thanks, Lynne May). It’s the kind of experience that… it makes me want to keep on doing this. I want to share it with as many people as possible.
I’d like to see whether we can get every single person who directly contributes to this deployment to meet the kids. Gary and Tomeu responded to a post from Lynne May about debugging Write – I wonder if they could help the students walk through testing it a little bit in a 10-minute video conversation. Luke is working with David and Bernie on migrating some Sugar Labs infrastructure into the capable hands of a group of RIT students; these are all services the kids will be learning and seeing and using, and being able to meet the people “behind the curtain,” so to speak, is pretty magical. 10-15 minutes is not long enough to really finish anything, to be sure - but enough to keep them going and excited, enough to keep us going and excited, enough to remind us why we do all this in the first place.
Melanie did a short update-video shoot with Lynne May on Tuesday night – it was done very late at night, and I love how Lynne May goes from exhausted to animated as she talks about the deployment. (The video becomes most interesting to me about 2 minutes in.) I livetranscribed – full transcript, as best as I can render it, posted below.
Transcript: Lynne May, 1st grade teacher
I’m testing – I’m going through the Sugar Activities to see what would be interesting for the kids.
I’m thinking how to introduce to unit to the children… talking about how communities – the general idea the kids have is that in communities, people get together, they work together, they agree on things, they have peace and love and they show respect.
We’re going to focus first on neighborhoods, the communities where they live. They actually have the homework of thinking about what they see in their neighborhood, so they have to figure out where they live, what neighborhoods they belong to, and what is their street where they live. I asked them to do some visualization of their neighborhood and they got to tell about what they saw on their way to school this morning from their house.
What? (Mel, from the side: You were talking at dinner about how they were really excited…) So I saw this neighborhood, and I said that we would study two other neighborhoods, I said our school community, which is the community where you work, so they’re ok with that, and then I said the third is an open source community called Sugar Labs. And I wrote “Sugar Labs,” and they said “Sugar? Labs?” And I forgot what one kid said, but I said “oh, lab, it’s like a laboratory.”
And I gave a very generic description of open source community – it’s where people who take time from their lives to develop software, applications, for other people to use for free, and then I referenced the DS and the games they have that they have to buy and pay money for. And I said the open source community people believe that there should be some things that should be available to anybody in this world for free. I think it’s like “huh?”
And that’s when I said “remember when my niece Mel, and…” and then they said “SEBASTIAN!” And then I said “Uh huh.” And (as kids:) “Oh! Oh!” And then they got really excited. (As teacher:) “We will not start right away!”
But then they… because I told their parents [about the SoaS pilot] in their [weekly classroom] newsletter and apparently some parents told their kids, so one kid, yesterday, Monday, when we got back from break, said “Are we going to work on the computer?” I said “Yes, aaand…” And then today he said “My mom said we’re gonna work on Sugar.” And then he said “My dad said we’re gonna have Sugar on a Stick.” So I said “What does that mean, Sugar on a Stick?” (As kid:) “Sugar on a Stick!” (As teacher, joking:) “You mean to say… something sweet, on a stick?” All he knows is that he’s got to be excited about Sugar on a Stick. He was quite excited about it.
But I think they are excited about it. So… So we’ll see. They might start saying “Oh, Lynne May, you said we’re going to have Sugar on a Stick! Where is it? Where is it?” By… tomorrow, they might say that. I’ll ask them to be patient.
(Melanie, behind the camera: So you’re actually going to start introducing it next week?) I will see if I can start introducing it on Friday. Or… yeah, maybe on Friday, or if not earlier, Thursday, to begin to. But it will be great to be introduce it when they have the computer, right? And I don’t think we are that ready yet to have the computers in the classroom. I mean me and the kids. Because first week back from break, I have to get them back on the routine. After being away for a week. You know, they sort of get excited like it’s the first week of school.
Anyway. So some of the things I’ve been thinking about is a [paper] journal that they would have a… when they will upload blog entries for, when they’re thinking about bug reports, that they would write there. (Melanie, from behind the camera: Battery runs out in 1 minute 30 seconds.) That’s ok, I won’t go on too long. So I’m working on tweaking on what it should look like. I have a prototype, I will see if that works.
That’s it for now. I’m pretty sleepy. (Melanie, holding the camera: That’s ok, thank you.) Bye.