Activity Team/Meetings/2009-03-13

Friday March 13th 2009 - 17:00 UTC

Agenda

• Activity Team coordinator announcement.
• activities.sugarlabs.org
  • Take ownership of activities.sugarlabs.org. The Activity Team will create a team of editors and admins to review and manage activity submissions.
  • Ask permission of activity authors to allow AT members to make releases. Without the ability of AT members to make releases, we will have fewer working & up to date activities on ASLO compared with distributions like SoaS (since it's common for distributions to package "trunk" activities). It's in everyone's interest to have the activities on ASLO be as up to date as possible.
  • Reintroduce idea of Activity Team Stamp of Approval and take care of these activities.
  • Discuss activity categories.
    • Introduce age range categories? Which ranges?

• Activity Team adoption of orphaned activities.
  • An "Activity Team" user now exists on ASLO so that we can post activities to ASLO without creating a user account for a possibly unreachable author.
  • We are considering also creating an activity Team user on Gitorious, which authors could give commit permission to in order to allow new releases to be made. This user could also be used when forking orphaned activities.
    • we shouldn't confuse activities authors by intervening to development process alsroot 18:44, 9 March 2009 (UTC)
    • common(RO to trunk, but fork/merge) access and ask authors only for releasing permissions - incrementing versions(do not confuse users), releasing(maybe) from cloned repos alsroot 18:44, 9 March 2009 (UTC)

• The Sugar Platform
  • Consider adopting SoaS as the standard test platform for ASLO activities. Assume that if SoaS works, other distributions will work as well.
  • Blobs in activities on ASLO.
    • Some of these blobs could be packaged and included in the Sugar Platform (gst-pluigns-espeak in Speak).
    • Others are truly activity specific (like C-libraries in Bounce and Colors).
      • We can oblige authors (by not approving non-conforming activities) to provide a standard set of variants which we determine. For example, x86/x64 for Linux. Another possibility is included standardized build scripts in the XO bundles and making a compiler suite part of the Sugar platform.
      • Alternately, we can add architecture choices to the ASLO platform selection.
        • Might be too complicated for kids to pick correctly.
        • Also requires authors to release multiple .xo bundles and set up cross-compilation.
        • How it will look like if a kid decided download activity from aslo and had to choose the right choice between Applications(0.82, 0.84), Platforms(Linux, BSD, Mac), Architectures(x86, x86_64, ppc, etc.)?

• GSoC 2009
  • SugarLabs is currently not planning to support activity development projects for GSoC 2009. Does the Activity Team want to encourage them to change this policy, or should we work under OLPC instead?

Log

http://meeting.laptop.org/sugar-meeting.log.20090313_1301.html