Updated Activities from the Mirabelle list
Summary
All Activities shipped in the Mirabelle release will continue to be shipped in Mangolassi if they pass a basic smoke test. These Activities will be updated so that Mangolassi ships the latest stable version of their code, which may mean that some Activities that were in Mirabelle will have improvements or new features in their Mangolassi version.
Owner
- Name: Mel Chua (I would love to do this feature with someone else and mentor them through the feature process, so if you'd like to learn how this works with guidance, please contact me and I'll help you with it through the entire release cycle.)
- Email: mel at sugarlabs dot org
Current status
- Targeted release: Mangolassi
- Last updated: Mchua 16:02, 2 August 2010 (EDT)
- Percentage of completion: 50%
Detailed Description
I think #Summary pretty much covers it.
Benefit to Sugar
More recent version of Activities get deployed and used, and hopefully feedback on those more recent version will be received.
Scope
For each Activity shipped in Mirabelle...
- Get the latest stable version of the Activity from either ASLO or git
- Smoke-test to see if that version of the Activity works. If yes, move on; if no, roll back a stable version until it does.
- Update the Fedora package for that Activity to that version of its code.
- Document (for Marketing, on a talking-points list when there is one for the Mangolassi version of SoaS) any significant feature improvements for that Activity that have occurred between its Mirabelle version and its Mangolassi version.
That's it; the updated packages will be automatically pulled into the Mangolassi image.
UI Design
Not applicable.
How To Test
Using the image under test, run each Activity from Mirabelle through the standard SoaS Activity smoke-test (which needs to be written).
User Experience
Users who have experienced the prior Mirabelle release of SoaS will notice that their old familiar Activities are still there, but that some have new features.
Dependencies
This feature depends on individual Activities, as it is a pull of their updated code.
Contingency Plan
None necessary, revert to previous release behaviour.
Documentation
No documentation, though we can and probably should link to individual usage documentation for each of these Activities being shipped.
Release Notes
We can't write this section until we have release notes for each upstream (Activity) being updated.