(added IAEP to the distribution because this is more about the education than 
the tech)
> simon wrote:
>  > 
>  > Ok, the reason why I brought this up is that git is one of our main 
>  > tools for development and if we ever want kids to start developing...

The idea that including git has educational merit is interesting, I think it 
exposes a wider issue than just git. Lets see if I understand the issues:

running git allows you to host a local repository and sync it with a master web 
hosted repository like git.sugarlabs.org

including git in the Sugar image would allow you to run git from the Terminal 
Activity

including git adds about 80MB to the OS image size

you can program your own Activity without needing git but it is very important 
if you are going to develop software collaboratively with others

only a very, very small percentage of Sugar users would be at a level where 
they would benefit from having git, but there is no reason to deny them git if 
it is not disadvantaging the majority of users (such as losing 80MB of storage 
space or tying up developer time that can be better used elsewhere)

this very small percentage would have Gnome rather than Sugar as their 
preferred desktop, they would be competent using other tools such as yum

some deployments, principally Uruguay, disable tools such as yum and Gnome, 
their biggest concern is students deleting Activities to make room for storing 
personal files, a significant but lesser concern is students rendering Sugar 
inoperable

suggested workarounds are enabling the yum command on locked computers and 
packaging git as a Sugar Activity (if you enabled yum would you also need to 
enable some way to uninstall too?)

the issue of locked laptops is wider than just git, for example students with a 
locked laptop can not install screen and use it to unbrick another laptop or 
talk with an Arduino. 

deployments may lack some of the software skills of the Sugar community, it may 
be possible to show them how to protect the functionality that is important to 
them without having to do a global lockdown of developer tools.

If I have got all of the above right then including git does not make sense. 
Producing an image which protects the features which deployments want to 
protect while minimally locking other features makes a lot of sense. If that is 
not practical then Sugarising git is a reasonable fallback but its only 
attacking the tip of the iceberg.

Tony
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Reply via email to