Changes

Jump to navigation Jump to search
m
Line 25: Line 25:  
{{Anchor|Next_Meeting}}
 
{{Anchor|Next_Meeting}}
   −
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.
+
Our next meeting is the SoaS v.4.0 planning meeting. Things to be decided:
   −
* Email feedback
+
* name/colors
** [http://lists.sugarlabs.org/archive/iaep/2010-May/010956.html Daniel Drake]
+
* release schedule
** [http://lists.sugarlabs.org/archive/sugar-devel/2010-May/024203.html Simon Schampijer]
+
* feature process
* [[SoaS Activity Criteria]]
+
* activity process as a subset of the feature process
* 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?
+
* dev-test-release cycle.
* Upcoming [http://teachingopensource.org/index.php/POSSE POSSE events] using SoaS as their project - [http://teachingopensource.org/index.php/POSSE_Worcester_State Worcester State (mchua, pbrobinson, and walterbender present)] and [http://teachingopensource.org/index.php/POSSE_RIT RIT (mchua present)] - and how we can take advantage of new contributors at these events
  −
* [http://lists.sugarlabs.org/archive/soas/2010-May/001289.html 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''' [http://people.sugarlabs.org/Tgillard/Activities-Index-ASLO.ods] that we could jointly edit.
  −
* Possible discussion :The Sugar-Creation-Kit-DVD and how it fits into Soas Picture [http://lists.sugarlabs.org/archive/soas/2010-May/001384.html]
  −
 
  −
Other things we're trying to find
  −
 
  −
* naming debate
  −
* versioning debate (marketing vs development)
  −
* PR debate (the last Marketing meeting) <link to log>
  −
 
  −
<pre>
  −
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
  −
</pre>
  −
 
  −
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 ==
 
== Procedure for Minutes and Logging ==
779

edits

Navigation menu