1 Jan 04:37
g.sl.o issues for Karma and perhaps other activities
Bryan Berry <bryan <at> olenepal.org>
2010-01-01 03:37:05 GMT
2010-01-01 03:37:05 GMT
I want to discuss some issues for managing Karma lessons on glso. Please let it be clear that I am not criticizing the infrastructure team __at_all__. I think they are doing a great job. The issues I am encountering have to do with underlying tools and some issues specific to developers working in countries w/ crappy bandwidth, such as Nepal.
Some of the main goals of the Karma Project are to get more developers in general involved in creating content for Sugar and to make OLE Nepal's content development more accessible and open to developers inside and outside Nepal. We have a full-time team of 7 sw engineers, 3 graphic designers, and 3 teachers working on content. It would be a crying shame if we can't work with the larger community.
One big problem for devs here in Nepal is that international bandwidth is both lousy and expensive. Conversely, w/in Kathmandu bandwidth is relatively high-speed and cheap. I have up to 2 Mbps w/in Nepal but get around 30 kbps for a site hosted outside Nepal.
The Karma repos are big and there will soon be many. The main Karma repo will be 10-15 MB and each individual lesson will be in its own repo, usually 2-4 MB. I hope to have about 60 individual karma activities under source control. That will be easily 200 MB. Transferring files of that size over slow international links will really cramp our development cycle. At the same time we need for the Karma lessons to be easily accessible internationally.
A working solution will have to start with a server inside Nepal hosting the Karma content. OLE Nepal can likely provide the server space. Would it be possible for us to set up our own instance of gitorious? My impression is that everyone is waiting to move to the gitorious instance but something is holding it up. Even if g.sl.o migrates to
gitorious.org how difficult would it be to set up an instance in Nepal. Or will it be too hard to set up a gitorious instance and we should just use something simple for Karma like cgit?
So say we do set up an instance of gitorious here in Nepal. How could we make it easy for others outside Nepal to access the code and contribute back? If you are outside Nepal, downloading from a server in Nepal also sucks due to the bandwidth issue. Would it be feasible to set up a read-only mirror of Nepal's repositories on the Sugar infrastructure?
I would like there to be a writable set of repositories on an international server but I can't imagine how the this mirror would sync w/ the Nepal server without lots of nasty conflicts.
Sugaristas, please let me know what you think
_______________________________________________ Sugar-devel mailing list Sugar-devel <at> lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
On Sat, 2010-01-02 at 12:01 -0500, Wade Brainerd wrote:
> How badly do you need a user friendly repository creator like
> Gitorious?
>
> If it's not important, you can just use GitWeb which is trivial to set
> up.
>
> I guess the important thing to consider is that Git can handle
> distributing and merging *code* changes across as many servers as you
> want. But if you want the metadata like project descriptions updated,
> you'll have to setup cron or a manual process like that.
>
> Honestly, 60 projects doesn't sound like too much work to set up by
> hand on both servers, compared with the amount of work to actually
> develop the lessons... Setting up a project on g.sl.o only takes a
> minute or so.
The problem with managing many repositories by hand is not just setting
them up. Once you have plenty of people accessing these repositories,
you'll need to implement fine-grained access control. The number of
access requests probably grows very quickly, proportionally to the
number of developers and repositories. Soon or later, your gitmaster
will become buried in support requests.
That said, Gitorious is a complex Rails application. Compared to other
web applications, it was quite hard to deploy and maintain. Indefero
(
RSS Feed