Sugar on a Stick meetings

Meeting details

Regular meetings for Sugar on a Stick take place on irc.freenode.net in #sugar-meeting, every Monday at 1900 UTC.

We use IRC for our meetings. If you don't have an IRC client (yet), you can use webchat - go to http://webchat.freenode.net and connect to #sugar-meeting, or click the screenshot below. (Replace "your_name" or the random ID provided with your name or some other nick you'd like to be known by.)

How we run meetings

With as much involvement as possible at all times.

The motivation is to have as many simultaneous actively participating people in the meeting as possible - ideally, at all times in the meeting, everyone in the meeting should be doing something really cool (and hopefully related to Sugar on a Stick) - not just waiting for their turn to speak. Think of it as a virtual version of the law of two feet.

Are YOU running a SoaS meeting? Take a look at How to run a meeting for an example of how a meeting is run, with commands listed out.

Agenda

Our next meeting is the SoaS v.3.0 Mirabelle release review, where we go over and look at how we did for that release cycle, and what we could do better for the next round. After this meeting, a second gathering will be scheduled specifically for v4 planning; it will take the feedback from this release review into account.

• Email feedback
  • Daniel Drake
  • Simon Schampijer
• SoaS Activity Criteria
• The more general notion of a feature process (are Activities a special type of feature?) on how things become supported/official parts of SoaS - for instance, how would the XS, or an alternative install method, become an official feature, and when?
• Upcoming POSSE events using SoaS as their project - Worcester State (mchua, pbrobinson, and walterbender present) and RIT (mchua present) - and how we can take advantage of new contributors at these events
• Tom has been doing a lot of QA for v3, it would be nice to figure out a regular development-test-release cycle for v4, with systematic test cases that other people can also run. A test case management system may be nice here. Possibly a table set up on the wiki like the Activities-Index-ASLO.ods [1] that we could jointly edit.
• Possible discussion :The Sugar-Creation-Kit-DVD and how it fits into Soas Picture [2]

Other things we're trying to find

• naming debate
• versioning debate (marketing vs development)
• PR debate (the last Marketing meeting) <link to log>

originally based on https://fedoraproject.org/wiki/Releases/13/Schedule
????-??-??     Decision to make v3 a Fedora Spin <link to email>
2009-11-17      Fedora 12 Release
               "Planning" & "Development "Begins" <-- did it?

2010-01-14     Approval as a spin http://lists.fedoraproject.org/pipermail/advisory-board/2010-January/007869.html (what does this mean?)

2010-01-26     Feature Submission Deadline                   } we can take these
2010-02-09     Feature Freeze-- supposedly planning and development ends here, but we didn't actually make this freeze explicit, which came back to bite us later on.

2010-02-18     Branch Fedora 13 from Rawhide
2010-02-16     Alpha Freeze
               Software String Freeze <-- we don't need this either
2010-03-09     Alpha Release
2010-03-23     Beta Freeze
2010-03-28     Creation of Creation Kit, Customization Guide

2010-04-13     Beta Release
2010-05-04     Final Freeze
2010-05-06     Compose Release Candidate
               Publicity push - creation of spins page, contributors portal, final revision of creation kit
2010-05-25     Mirabelle Final Release

We should have released a release schedule at the beginning and actually consistently referred to it as a roadmap.

What we need to fail less at is communicating the freezes and their importance. The community needs to understand that it's a *freeze* and not "Sebastian says it's cold outside and he doesn't want to commit stuff but will have to anyway because our software sucks". So a *freeze* means stuff *has* to be in shape by then. This applies to Alpha / Beta / Final freeze. While we *hypothetically* can push stuff, it requires extra permission. So what we probably need is testing deadlines, because if stuff "works" by the freeze, it's too late, because it'll have to be "pushed". We already communicated this waaaaaaaaaaaaaaaay better than for Blueberry, but it's still an issue (see: Read breakage #1900).

Maybe one of the things that happened was that we assumed people knew what a freeze was, but folks unfamiliar with the software release cycle may not have realized what was going on.

We didn't really have consistent QA this release cycle. We had some inconsistent QA (thanks, Thomas) which is better than nothing, but an improvement would be to actually have some sort of develop-test-release cycle (emphasis on the "cycle" part, and the existence of the word "test" in there).

We also didn't have consistent communication with deployments. Actually, we only had communication with one deployment for the most part, and it was very good in the beginning (see http://blog.melchua.com/category/soas/)

Good things:

• http://download.sugarlabs.org/soas/docs/creation-kit/
• http://download.sugarlabs.org/soas/docs/customization-guide/
• http://wiki.sugarlabs.org/go/Sugar_on_a_Stick
• http://spins.fedoraproject.org/soas/
• Weekly meetings starting (mostly for v4, but...)
• More consistently driving communications to the mailing list
• More than one person with commit privs to the kickstart file, etc.

Procedure for Minutes and Logging

See the instructions on how to run a meeting.

Minutes

• 2010-05-31 v3 Mirabelle release review meeting (regular weekly time)