Difference between revisions of "Platform Team/Package Management System/Getting started"
Inkyfingers (talk | contribs) (update - my test in progress) |
|||
| Line 6: | Line 6: | ||
::: "It is important to stimulate users into becoming doers—to modify existing activities, and to share the results of their experiments with other people, viz., a distribution method should handle different variants of the same project."; | ::: "It is important to stimulate users into becoming doers—to modify existing activities, and to share the results of their experiments with other people, viz., a distribution method should handle different variants of the same project."; | ||
::: so Sweets seems to be aimed at those about to graduate to the software sharing stage of Sugar learning. Do you think that this stage can be assumed for someone who has not launched or loaded Sugar before? (''Someone'', here, refers to a significant fraction of the population of beginning Sugar learners.) To this goal, significant stimulation efforts seem to be focused on providing malleable software at the Activity level, so learners can discover the gratification of creating new 'code' products. Sweets seems a bit advanced from that early stage. Clearly, a, or ''the'', goal is to lower the effort required for robust doer<->doer sharing. Seems like we need to advance by iteration with 'early adopters' and continue to eliminate all the 'hitches' and obstacles that discourage the vast majority of new users yet to become doers. --[[User:FGrose|FGrose]] 22:49, 3 December 2011 (EST) | ::: so Sweets seems to be aimed at those about to graduate to the software sharing stage of Sugar learning. Do you think that this stage can be assumed for someone who has not launched or loaded Sugar before? (''Someone'', here, refers to a significant fraction of the population of beginning Sugar learners.) To this goal, significant stimulation efforts seem to be focused on providing malleable software at the Activity level, so learners can discover the gratification of creating new 'code' products. Sweets seems a bit advanced from that early stage. Clearly, a, or ''the'', goal is to lower the effort required for robust doer<->doer sharing. Seems like we need to advance by iteration with 'early adopters' and continue to eliminate all the 'hitches' and obstacles that discourage the vast majority of new users yet to become doers. --[[User:FGrose|FGrose]] 22:49, 3 December 2011 (EST) | ||
| + | :::: From one side, it is original intention to make Sweets useful for 'early doers', e.g., instead "./setup.py dist_xo && run Browse && go ASLO and login there && upload your .xo" it is only "sweets commit". From another side, Sweets is only low level technical tool, PMS, with strong idea exactly to | ||
| + | "It is important to stimulate users into becoming doers—to modify existing activities, and to share the results of their experiments with other people, viz., a distribution method should handle different variants of the same project.". And it is possible to create several frontends for different levels of 'early adopters' to make them doers. The one effort is might be undertaken within Peru pilot program, where it require new software/activity for having "offline ASLO" (and this application/activity might be also stimulate people become doers). | ||
| + | |||
Could you [originally addressed to [[User:Inkyfingers|Inkyfingers]]] look at the documentation with the eye toward drafting an introductory posting and page for new non-technical users? If you could outline, or outright draft, an introduction, it would be a great service to us (and we need to exploit your 'newness' before it rapidly expires, if it hasn't already.) and much appreciated! --[[User:FGrose|FGrose]] 21:23, 2 December 2011 (EST) | Could you [originally addressed to [[User:Inkyfingers|Inkyfingers]]] look at the documentation with the eye toward drafting an introductory posting and page for new non-technical users? If you could outline, or outright draft, an introduction, it would be a great service to us (and we need to exploit your 'newness' before it rapidly expires, if it hasn't already.) and much appreciated! --[[User:FGrose|FGrose]] 21:23, 2 December 2011 (EST) | ||
Revision as of 08:11, 5 December 2011
Sweets introduction
Aleksey has prepared a new distribution model for Sugar called Sweets, and asks about introducing it to non developers, #3249.
- Sorry, but the ticket was about Sweets Usage, not about Sweets Distribution. alsroot 01:18, 3 December 2011 (EST)
- OK, good example of the confusion possible. From Platform Team/Sweets, the assumption is made that,
- "It is important to stimulate users into becoming doers—to modify existing activities, and to share the results of their experiments with other people, viz., a distribution method should handle different variants of the same project.";
- so Sweets seems to be aimed at those about to graduate to the software sharing stage of Sugar learning. Do you think that this stage can be assumed for someone who has not launched or loaded Sugar before? (Someone, here, refers to a significant fraction of the population of beginning Sugar learners.) To this goal, significant stimulation efforts seem to be focused on providing malleable software at the Activity level, so learners can discover the gratification of creating new 'code' products. Sweets seems a bit advanced from that early stage. Clearly, a, or the, goal is to lower the effort required for robust doer<->doer sharing. Seems like we need to advance by iteration with 'early adopters' and continue to eliminate all the 'hitches' and obstacles that discourage the vast majority of new users yet to become doers. --FGrose 22:49, 3 December 2011 (EST)
- From one side, it is original intention to make Sweets useful for 'early doers', e.g., instead "./setup.py dist_xo && run Browse && go ASLO and login there && upload your .xo" it is only "sweets commit". From another side, Sweets is only low level technical tool, PMS, with strong idea exactly to
- Sorry, but the ticket was about Sweets Usage, not about Sweets Distribution. alsroot 01:18, 3 December 2011 (EST)
"It is important to stimulate users into becoming doers—to modify existing activities, and to share the results of their experiments with other people, viz., a distribution method should handle different variants of the same project.". And it is possible to create several frontends for different levels of 'early adopters' to make them doers. The one effort is might be undertaken within Peru pilot program, where it require new software/activity for having "offline ASLO" (and this application/activity might be also stimulate people become doers).
Could you [originally addressed to Inkyfingers] look at the documentation with the eye toward drafting an introductory posting and page for new non-technical users? If you could outline, or outright draft, an introduction, it would be a great service to us (and we need to exploit your 'newness' before it rapidly expires, if it hasn't already.) and much appreciated! --FGrose 21:23, 2 December 2011 (EST)
Much of the wiki documentation for Sweets is highly technical and aimed at Platform packagers. This page, Platform Team/Infrastructure, with its graphics and short summary helped me grasp the big picture. The problem is now to extract the essential minimum for a new interested learner to try this new technology. It will take some effort and, no doubt, some iterations. --FGrose 21:43, 2 December 2011 (EST)
Also look at: Sweets Installation satellit_ 9:03 2 December 2011 (PST)
- Sure. I will test Sweets on (Debian (kernel 2.6.32) n/w - wait for wheezy) or Mint 11 (n/w) or Mint 12 (kernel 3.0.~) and see what my notes look like. --Inkyfingers 06:10, 3 December 2011 (EST) and edit --Inkyfingers 10:45, 4 December 2011 (EST)
- Here is my log for fedora 16 gnome3-shell install of sweets-sugar:
Target Audience
What sort of presentation to use? As a "can opener" can I identify three people in my target audience?
- Not yet ... (Tom might be a GCompris user / learner-contributor?)
- Shall we expect visitors from this community? http://www.raspberrypi.org/. They will be interested to see if Sugar will cross-compile to ARM. (I think)
Features will be the same for all three audience members. Just to record my first impressions, these three links got me up to speed....http://0install.net/why.html ... http://packages.debian.org/wheezy/gnome-packagekit ... Platform_Team/Guide.
Advantages - What are the advantages for Tom Dick and Harry? Are we talking educational or productive?
Benefits - Are the benefits different for each? Does Sweets open different doors for each? --Inkyfingers 03:13, 4 December 2011 (EST)
- I find Sweets Distribution easier to use for Ubuntu' and its Derivatives (Adding an additional Repository to synaptic) as the packages are pre-configured, ready to use.
- Sugar via Sweets has a wider applicability to linux OS's but requires a more experienced user. satellit_ 7:17 4 December 2011 (PST)
- " For now, sweets knows only enough about the glucose dependencies to install them from native packages in Debian, Ubuntu, Fedora, Mandriva, openSUSE, and Gentoo."