Posts that are sugar-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 »
I found this mailing list conversation snippet to be very insightful, and wanted to share it.
Scott: “Open to critique” isn’t quite the same as “responsive to critique”. From an outside perspective, it seems that frequently SugarLabs is just not listening to people who offer contrary opinions. This is better than flaming them, but maybe not as good as it could be. For an end-of-year report, I’d like to see instances enumerated where SugarLabs actually internalized some outside critique and responded in a positive way — some concrete change made to the UI, or Sugar, or to process. That would be more convincing that simply stating, “we are now open to critique”.
Bernie: We’re definitely intimidating to non-technical people. At least, this is what I sensed at the Realness Summit. OLE also seems to be doing a better job at connecting with educators. I’m not completely sure what corrective actions should be. We might need to do some work on the wiki, maybe add web forums, which non-geeks tend to prefer…
Scott: I suspect that the answer to this problem does not involve installing additional software.
Later in the day, Jeff and I were having this conversation on #teachingopensource.
Jeff: Is IRC really a barrier to entry? maybe I have simply been using it too long, but it seems immediately recognizable to me. I think one barrier might be the attitudes that crop up. Even with emoticons, sometimes it’s hard to discern intent. Hard enough in email, but sometimes devastating in real time.
Mel: Actually, yes. I had a really, really hard time figuring out IRC. First, figuring out that it existed and I had to use it. Then how to get it, how to set the software up. Then what the heck networks and channels and whatnot were – and why channels? my IM paradigm was “you have a buddy list and you ping people individually.” So “chatrooms are the default!” wasn’t hard to understand once I realized it, but it took a while to realize because I wasn’t looking for it.
And then “oh man, who are all these people? I am nervous about pinging them, will they yell at me?” And then all the /commands I had to remember. It was so bewildering and terrifying and new and it was being used as a way to present new information to me at the same time, sort of like… taking your first calculus class in… Mandarin, if you’ve also just started studying Mandarin as a foreign language. You can’t concentrate much on the calculus because you’re going “zomg it’s in CHINESE.”
It’s hard to remember how hard things can be, especially when you’re surrounded by a community of people who are the ones who self-selected and made it past that hardness. By definition, if you’ve gotten into FOSS, the current participation mechanisms worked for you… so why fix them?
Because we want others to join us.
Tuesday, July 13th, 2010 | fedora, olin, olpc, sugar, teaching open source | 9 Comments »
Notes I wrote up months ago that have since been found by others to be useful. Posting for posterity. Basically, these instructions are for how to set up an always-on logger for IRC (chat) – helpful for being able to hear the conversations others are having about the project you’re working on while you’re away. I am assuming a fair amount of background knowledge here, but the content is remixable, so feel free to yoink/improve/etc.
1. ssh into the box you have an account on – for instance, Sugar Labs folks can use sunjammer (aka people.sugarlabs.org) by requesting an account at http://wiki.sugarlabs.org/go/Sysadmin/Shell_account_request
.
2. Run these commands (comments in parentheses).
screen
(a dialog will pop up, hit return to kill it)
irssi
(you’ll get a mostly blank screen, with a stripe across the bottom with the
time and a number [1] in brackets – that’s the window list – and then a line
below that with [(status)] in it, which is the description of the window that
you’re in, and the place you type the rest of the commands.)
/connect irc.freenode.net
(and then, if you want, /msg nickserv identify <password> to sign in.)
/set autolog on
(it’ll start storing things in ~/irclogs in self-explanatory filenames)
/join #sugar
(and whatever other channels you may want to be in)
(You’ll notice that every channel you join opens up another window – the first
channel will be in window 2, the next in window 3, and so forth. Use ctrl-p
(previous) and ctrl-n (next) to switch between windows, or alt-NUMBER to jump
to the NUMBERth window.)
(You’ll also notice that the numbers for each window light up in different
colors when someone joins/leaves a channel (blue), talks in a channel (white),
or calls your name in a channel (pink).)
(All the normal IRC commands work as expected, and so does tab-completion.)
(a note on /whois: if you have a PM window open for that person, the whois
information will appear in the PM window. Otherwise, it will appear in window
1.)
3. When you want to stop, do
/away <away message>
and then detatch from screen, which is
CTRL-a, d
(ctrl-a followed by d)
which will dump you in your normal sunjammer shell outside of screen.
Or you can just kill the terminal by typing
~.
or whatever.
When you log in again, restart the screen session with
screen -raAd
…and you’ll be back. If you then type
/away
…you’ll see all the messages sent to your nick in the meantime in window 1,
and you’ll be set to not-away.
4. More docs at http://www.irssi.org/documentation/startup
and http://quadpoint.org/articles/irssi
.
I mostly find irssi useful for being always-on all the time and having backlogs
of conversations that have happened while I’m away. It also means that anywhere
I have ssh, I have IRC.
Wednesday, July 7th, 2010 | fedora, sugar, teaching open source | 2 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 Sugar Labs Oversight Board (SLOBs) has had trouble getting together on IRC recently because of everyone’s crazy schedule, so today some of us got together in-channel and got through the list of outstanding topics as best we could. It wasn’t an official SLOBs meeting – with only myself, Tomeu, and Chris Ball, we lacked quorum and couldn’t make any official decisions – but we moved things forward as best we could, because these issues are pressing.
Remember, nothing says that anyone (you don’t have to be a SLOB!) can’t move things forward, SLOBs-fu is only needed for the final formal vote! The full log is available, and I’ve added it to the list of past logs while noting that it wasn’t an official SLOBs gathering, for clarity. Here’s what we covered:
- F11+0.88+XO-1.* as a SL project – Bernie had sent in a request on behalf of Paraguay Educa and Activity Central to make Fedora 11 with Sugar 0.88 builds for the XO-1 and XO-1.5 a new official project. It wasn’t clear to us what resources they needed; we pointed out that they could get infrastructure/hosting without being an official “SL project” (and indeed without asking SLOBs!) and asked what else they needed – trademark permission, etc? Tomeu brought up that SL projects were the ones that SL teams (Marketing, Design, Development, etc.) were expected to support, so it’s not clear that this would be the appropriate designation for the F11+0.88 builds – there may be a more appropriate upstream for the project to be under (Paraguay Edcua, Activity Central, OLPC, Fedora, etc.) and then SL could partner with that project instead of being the umbrella org for it.
- Ooo4Kids logo display request – Ooo4Kids asked if they could display our logo on their “partners” page, but we’re blocked by not being able to find the original text of the request for this. If you know where to find this, or who at Ooo4Kids to contact about it, please let us know!
- Trademark usage applications – A number of local labs have asked for permission to use the SL trademark, but again, we’re blocked by not having the original request text. If you’re from the Colombia, Paraguay Educa, Argentina, Chile, Peru, or DC Local Labs, please help us find your request!
Since all three of these are continuing discussions, and we’ll be continuing those discussions on-list, I’ve linked to those discussion threads from the agenda for next week. (The other two things on the list for next week are “Review of RM search” and “Motion and possible vote on Sugar certification,” – I am not sure what the latter means, so clarification would be great, what’s the motion we’re looking at?)
Question for all Sugar folks: what do YOU think the most pressing problems in our community are? That’s what SLOBs should be addressing – so please tell us what our biggest (non-code) bugs are.
Friday, June 25th, 2010 | sugar | 2 Comments »
POSSE alumni Kristina Striegnitz and her student Kirk Winans are looking to do some linguistics-learning hacking (tools for language learners) and would love ideas for what to work on; they’d like to put the Leitner system (where the computer tracks your correct/incorrect answers and brings up things you answered incorrectly more frequently in the future) into something fun. Any suggestions? I left mine here (awaiting comment moderation as I type this).
Olin alumni Janet Tsai wrote a proposal for using yoga as a way to explain engineering. I think I need the reverse equivalent – engineering as a way to explain yoga (or running, or whatever) – I have very little physical awareness, but math and physics make things make more sense; I understood dancing much better once folks like Gui and Andrew began to explain what I should do in terms of adjusting spring constants and whatnot. I wonder if I can get someone to teach me some sport – almost any sport, but bonus points if it’s a martial art – with that sort of mentality. Too bad Janet lives in a different state…
Supertalent makes little flash drives that would make pretty awesome necklaces. Next time my mom insists I have some form of jewelry for some formal occasion, if given enough advance warning, I might just do that. (“What’s that on your necklace?” “Fedora 13. Want to install it on your computer?”) I do not like jewelry at all, but I keep on getting bothered to wear it, and figure that having one necklace and one set of earrings and perhaps one bracelet I can tolerate is better than constantly being forced to borrow stuff I don’t like. Too bad I didn’t get a set of white LED earrings when Alex Wheeler’s FBE class made them; they are ridiculously expensive when you get them online. Maybe I’ll ask her how to make them if I find out I will need this stuff again.
Tuesday, June 22nd, 2010 | fedora, sugar | 3 Comments »
Lessons I’ve learned today whlie hanging out in the Sugar IRC channel (#sugar) and want to pass on to Bao (a student from Arlington who’s hacking on the IRC Activity this week):
Cloning a personal branch for development is really easy and a good idea so that unstable changes don’t get pushed to mainline. This is particularly important for developers running the bleeding-edge sugar-jhbuild code, since it pulls directly from the git repos, so an experimental commit there could break things for them. (Fortunately, the IRC Activity isn’t pulled into sugar-jhbuild by default, but it’s a good habit to get into, for when you start working on code that is.)
It’s difficult to interpret text communications when you’re new sometimes. What an experienced developer may regard as friendly suggestions for improvement (that they’ve spent their valuable time helpfully trying to write up) may be received by newcomers as a big stick smacking them down and discouraging their project contributions. By default, assume that people are trying to be helpful and put forth constructive criticism because they want your project to succeed, and for you to stick around.
git config –global color.diff auto enables diff coloring in git. Pretty! Secifically, the diff coloring will show you EOL (end of line) spaces – they’ll display as red blocks. These EOL spaces don’t really make a difference when you’re tinkering with your own code, but when you start upstreaming your work, they make patches very annoying for reviewers and people trying to merge your patches in. In general, it’s a good idea to set your editor to remove EOL spaces automatically.
Thanks to Sascha Silbe for teaching me (and others in the channel) about this stuff today. Sascha writes:
“I can remember the pains of going through the SL review process for the first time rather well, so I try to make sure new contributors learn how to do it ‘right’ early on. It means a lot less work and less waiting on yet another review iteration.”
I’m writing this up because I find that teaching something to someone else makes it more likely that I’ll learn it myself, and this is all stuff that I want to learn. Mm, hacking-fu++. Thanks, Sascha. This is the kind of knowledge-spreading that we need to do with new contributors in order to grow our capacity to hack on things – it’s how novice hackers (like myself) learn how to be productive.
Wednesday, June 16th, 2010 | sugar | No 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 »
