Changes

#*At the time of writing there are almost 400 sugar activities. Projects like sugar on a stick have widen the community for these activities (like they can be used by Fedora users as well). Still that is possible only for the packages that are packaged for Fedora (making the rpm, going through the review process and all that). What I am trying to do is spread it even more. People who want to use activities on their Fedora box will just add the repo and install them. There's no need for them to be approved for Fedora repo. This is true for any other rpm based distro. Further there is no need of maintainers who need to follow the development and build new rpms. (Currently there are packaged activities for Fedora where there are no further rpm issues due to lack of maintainers). It is even better to extend this to other package managing systems as well like deb. But I have no experience with that at the time of writing so I will for now just stick to rpm.

#*At the time of writing there are almost 400 sugar activities. Projects like sugar on a stick have widen the community for these activities (like they can be used by Fedora users as well). Still that is possible only for the packages that are packaged for Fedora (making the rpm, going through the review process and all that). What I am trying to do is spread it even more. People who want to use activities on their Fedora box will just add the repo and install them. There's no need for them to be approved for Fedora repo. This is true for any other rpm based distro. Further there is no need of maintainers who need to follow the development and build new rpms. (Currently there are packaged activities for Fedora where there are no further rpm issues due to lack of maintainers). It is even better to extend this to other package managing systems as well like deb. But I have no experience with that at the time of writing so I will for now just stick to rpm.

#*The idea is to maintain a ini file like file for each activity and generate the spec file out from that and finally generate the rpm. There is [http://wiki.meego.com/Spectacle Spectacle], a tool to generate spec out of a ini file and [http://rm-rf.ca/tito Tito] which can be used to build rpm from the spec file.

#*The idea is to maintain a ini file like file for each activity and generate the spec file out from that and finally generate the rpm. There is [http://wiki.meego.com/Spectacle Spectacle], a tool to generate spec out of a ini file and [http://rm-rf.ca/tito Tito] which can be used to build rpm from the spec file.

 

#What is the timeline for development of your project? The Summer of Code work period is 7 weeks long, May 23 - August 10; tell us what you will be working on each week.

#What is the timeline for development of your project? The Summer of Code work period is 7 weeks long, May 23 - August 10; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (July 6-13); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.

#*July 01 - 06

#Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.

#Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.

== You and the community ==

== You and the community ==