5,705
edits
Changes
Jump to navigation
Jump to search
Line 9:
Line 9: − + + +
Platform Team/Sugar Packaging Management System (view source)
Revision as of 13:54, 26 April 2010
, 13:54, 26 April 2010→Purposes
Sugar is not unique when faced with questions like how to deploy new features to users. There are well-tested and robust models in the FOSS world when projects follow regular release schedules, e.g., 6-month, support, long-time supported releases, etc. But there could be cases when sugar has its specific needs:
Sugar is not unique when faced with questions like how to deploy new features to users. There are well-tested and robust models in the FOSS world when projects follow regular release schedules, e.g., 6-month, support, long-time supported releases, etc. But there could be cases when sugar has its specific needs:
* The most broad sugar audience is teachers, students, schools and other educational organizations. Thus, we can not rely in all cases on the fact that all sugar users will use only the latest stable sugar release. For example, the latest OLPC sugar is 0.82, next will be 0.84, but the latest stable version is 0.86.
* The most broad sugar audience is teachers, students, schools and other educational organizations. Thus, we can not rely in all cases on the fact that all sugar users will use only the latest stable sugar release. For example, the latest OLPC sugar is 0.82, next will be 0.84, but the latest stable version is 0.88.
* Many developers participate on a casual basis, thus, supporting several sugars (one for stable OLPC, one for next stable OLPC, and one for the latest stable upstream) for their activities is overkill. As such, people support only one branch, and either drop other user categories, or do not implement useful features from the latest sugar (like the new toolbar design).
* Many developers participate on a casual basis, thus, supporting several sugars (one for stable OLPC, one for next stable OLPC, and one for the latest stable upstream) for their activities is overkill. As such, people support only one branch, and either drop other user categories, or do not implement useful features from the latest sugar (like the new toolbar design).
* One of original sugar purposes is stimulating people to hack existed code and share their code. Having (in ideal) such huge heap of code we can't rely on the fact that all these activities will work on a bunch of sugar releases. For example, if someone took Record activity (maybe not last version) and implemented new feature, he just wants to share his hack, not test this new code on several Sugar Platforms, ask QA to test it, ask ASLO editors to review etc., just share.
So, the right answer could be a more scalable and decentralized development model. That doesn't mean we should follow only a decentralized model, but we can effectively mix both—a centralized model with the core team and regular releases, and add an optional, decentralized model.
So, the right answer could be a more scalable and decentralized development model. That doesn't mean we should follow only a decentralized model, but we can effectively mix both—a centralized model with the core team and regular releases, and add an optional, decentralized model.