Posts that are soas-ish
From the latest Sugar on a Stick (SoaS) meeting minutes:
We spent most of our time on the next big urgent milestone: getting testable Sugar 0.90 images out the door for upstream Sugar QA. This isn’t an official SoaS release, but since SoaS is an easy way to get an instance of Sugar up and running, it’s great for testing, and since we’re going to include the 0.90 release of Sugar anyway, Simon has asked us to include it in our test builds by a certain date so it can be used to test the Sugar environment itself. By “certain date,” I mean that the 0.90 Beta release is this Wednesday; here’s what has to happen preferably before then. (For the Fedora folks in the audience, SoaS is a Fedora Spin.)
- Simon updates the sugar, sugar-toolkit, sugar-datastore, sugar-presence-service, sugar-artwork, telepathy-gabble and telepathy-salut packages in Fedora to the correct code versions.
- Mel gets 3 people to test these packages and give them karma in Fedora’s system, which will put them in the stable repositories. I’ll be writing instructions on how to do this shortly.
- Simon or Peter or someone takes the next daily build and makes sure it boots, then announces the test image.
What this means for you, o reader: if you run Fedora (or can run Fedora in a VM, or can follow written instructions on how to do exactly this), you (yes, you!) can help us with 0.90 testing this week. We’re going to have instructions for this coming out once the code is ready to be tested; it should take less than 2 hours (hopefully less than 1) to do your setup and testing from start to finish, and you won’t need any prior experience. We’ll be using the same test setup for Sugar in the future, too.
The catch is that because we’re under intense time pressure to meet release deadlines, the time between when we can say “we’re ready! We need help!” and when we need the testing finished by is going to be VERY short. So this is a heads-up letting folks know this call is going to be coming.
Stay tuned for more QA news in Sugar land! (dun dun DUNN!)
This blog post written under more sleep deprivation than is probably good for me. I’m going to go to bed now so I’ll be more useful in the morning.
Monday, August 30th, 2010 | fedora, soas, sugar, testing | No Comments »
As promised, I kicked our SLOBs agenda items forward for another week. Turns out you can do a lot without needing to vote. :) Our meetbot does some truly awful meeting minutes formatting, but here’s the summary:
What else do people consider the most pressing topics to the future of SL? How are we doing? Are we reaching our goals? (What are they?) These should be the agenda items we discuss.
Sunday, July 11th, 2010 | soas | No Comments »
Dear lazyweb: there must be a simple answer to this. I’m trying to write a shell script that a cron job can run every week to update our Sugar on a Stick (SoaS) test image repository. The ticket in question is Sugar Labs #2058. Longer explanation than usual given so those new to the dev/test/release cycle can follow along.
Basically, SoaS is a Fedora Spin, so we get nightly composes made here (as in, “Fedora automagically builds our .isos for us so we don’t have to”). In order to (we assume) save on disk space, the Fedora servers only store the latest nightly compose – once a new .iso is made, the old one is gone forever, bwahaha!
This is fantastic for developing, but not so much for testing. Expecting testers to keep up with daily builds is a bit much, and it’s putting a burden on people who are downloading them every day (possibly even getting into trouble with their ISP), so we decided to go with a weekly test cycle – each Thursday evening we’d designate the most recent image as the “image under test” and point everyone there. That way, developers would also know exactly what image people were finding bugs in each week.
Problem: in order to (we assume) save on disk space, the Fedora servers only store the latest nightly compose - once a new .iso is made, the old one is gone forever, bwahaha! So we need to grab the most recent image – which has a special naming – at that time and pull it down to the Sugar Labs servers so we have the files at http://download.sugarlabs.org/soas/test/ (We’re also storing the old test images so we can go back and forth between them Since the builds do contain their build date in their name, and we can’t predict ahead of time what the build date and time are, we don’t know the exact filename to pull.
So we’re basically looking for a shell script that will:
- Pull the latest iso and checksum from the SL servers
- Rename the checksum so it matches the datetime stamp of the iso (the checksum is currently called – rather unhelpfully – “CHECKSUM-i386″).
- Update the symlinks so that http://download.sugarlabs.org/soas/test/soas-i386-test-latest.iso and http://download.sugarlabs.org/soas/test/soas-i386-test-latest-checksum.sha point to the latest iso and checksum that were just downloaded.
This probably requires some sort of weird wildcard bash-fu that would take me multiple hours to inelegantly figure out, and someone else 5 minutes to write a one-liner to solve.
Can haz halp?
Saturday, June 26th, 2010 | fedora, soas, sugar, teaching open source, testing | 5 Comments »
The email I sent my team today as a “what did Mel do?” update:
00:18 * mchua has had a great day.
00:19 < mchua> When college professors start high-fiving each other across the classroom like excited kids because they got a button to work on a Sugar Activity, and then head out for ice cream, it is a Good Day.
I’m too behind/tired to be more verbose – turns out it’s difficult to simultaneously teach at and document a POSSE (probably due to that blasted 3 hours of driving per day – will hopefully do better next week). But betwen Friday noon and Sunday at 6 when the RIT one starts, I’ll spew logs from this one.
Theme: “Development”
Big idea: Sometimes, you’ve just got to dive in and work on the code… together.
Skill: Making contributions to an open source project “in the wild.” (In this case, the Measure Activity.)
Full logs:
Of the three, the notes for the last one are the most interesting – the notes for maddog’s talk are essentially a paraphrased (brief) transcript of his 1.5 hour presentation on “how FOSS teaches you twice.”
Wednesday, June 9th, 2010 | fedora, olpc, soas, sugar, teaching open source | No Comments »
Some of you may have noticed some new faces around the Sugar community – we (Walter Bender, Peter Robinson, and I) are hanging out with a group of professors (mostly from the Worcester area) who are in town this week for POSSE (Professors’ Open Source Summer Experience), a workshop for learning how to get their students involved contributing to open source projects. (In this case, Sugar, with Fedora as a dev platform.)
They’ve been learning to hack Sugar all week, and are in fact in #sugar at this very moment tinkering away on the Measure Activity. Their feeds haven’t yet been added to Planet Sugar Labs (those requests are still pending), but you can read some of their (great!) reflections so far on Planet TOS.
So if you have a moment, pop in and say hello to:
- Peter Froehlich (Johns Hopkins) – pgf
- Karl Wurst (Worcester State College) – kwurst
- Nadimpalli Mahadev (Fitchburg State College) – Mahadev
- Kristina Striegnitz (Union College, Schenectady, NY) – kis
- Jerry Breecher (Clark University, Worcester MA) – diamond
- Mihaela Sabin (University of New Hampshire) – mihaela
- Gary Pollice (Worcester Polytechnic Institute) – gpollice
- Aparna Mahadev (Worcester State College) – aparna
Next week we’ll have another – slightly larger – batch from RIT doing the same thing, with myself, Chris Tyler, and Luke Macken focusing more on how to make Fedora a better environment for running/deploying/developing Sugar – if you have any thoughts in this direction, please send comments our way! (Things we’ve come up with so far: general Python development stuff, liveusb-creator hacks, SVG rendering working strangely in different recent versions of Fedora… we need to turn this into a proper ticket queue. Ideas welcome! What are the little annoyances you always wanted to fix? We’ll do our best to take them on.)
Wednesday, June 9th, 2010 | fedora, olpc, soas, sugar, teaching open source | No Comments »
Readers of Planet TOS will notice the addition of a number of new bloggers to your daily firehose of feeds. Please welcome the POSSE Worcester State crew, who will be hanging out in #teachingopensource (irc.freenode.net) all week working on Sugar on a Stick and learning firsthand how to dive into the deep end of a FOSS community. Pop into the channel, say hello, introduce yourself, tell your stories – some folks are new to IRC, some are new to wikis, and some are new to blogging, but everyone is learning fast; I’m completely stoked about our POSSE Worcester cohort. As you get to know them more over IRC/wiki/blogs, you’ll see why. ;)
I’ll write more when I’m slightly closer to full consciousness (need food and a nap first, I think – today was far too early of a wakeup), but in the meantime, here’s what we did on Monday. The remainder of the week will be spent picking a Sugar Activity and championing it as a feature for SoaS v4 by making it meet the Activity (Inclusion) Criteria (in other words, “taking it through the feature process“).
We’ve got some topic suggestions for tomorrow (in addition to the things we were already planning to cover, which are basically “getting code, finding out what bugs others have already found to work on, and sending patches back”), but feel free to add others if you’ve got ideas.
Monday, June 7th, 2010 | soas, sugar, teaching open source | No Comments »
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!
Friday, June 4th, 2010 | fedora, olpc, soas, sugar, teaching open source | No Comments »
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:
* http://wiki.sugarlabs.org/go/Sugar_on_a_Stick_deployment_process
* http://wiki.sugarlabs.org/go/Sugar_on_a_Stick_release_process
* http://wiki.sugarlabs.org/go/How_to_fix_an_Activity_bug
* http://wiki.sugarlabs.org/go/How_to_fix_a_sugar-core_bug
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.
Monday, May 24th, 2010 | fedora, soas, sugar, teaching open source | No Comments »
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.[0]
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?)
[0] 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.”
Thursday, May 6th, 2010 | soas, sugar | 1 Comment »
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.
Examples:
What would make your Sugar hacking easier and more fun?
Monday, May 3rd, 2010 | soas, sugar | 1 Comment »
