[IAEP] ASLO updates

[Bernie Innocenti]

[cc += dfarning, alsroot, systems@]

El Wed, 14-10-2009 a las 17:47 -0700, Josh Williams escribió:
> I've made some bug fixes to the new ASLO design, I've tested it lightly 
> and it seems to work in all major browsers (even ie6). If you have a few 
> moments, please test it out (download/upload activities, browse around) 
> and let me know if you see any display bugs or major usability issues.
> 
> http://activities-devel.sugarlabs.org/en-US/sugar/

All links to activity bundles appear to be broken :-(
For example:

 http://activities-devel.sugarlabs.org/en-US/sugar/downloads/file/26072/xpi/labyrinth-7.xo?src=addondetail

I'm not sure how to fix it, but I can imagine that it may be related
with moving the activity bundles from their old location
(/srv/www-sugarlabs/activities/files) to the upload directory
(/srv/upload/activities/) done by Dfarning in order to enable
Mirrorbrain.

Earlier today, alsroot asked me to fix some permission issues that would
prevent aslo from writing new activities in the new location. Now I'm
also noticing that there's still a copy of the activities in the old
location, and it is also bigger by 40MB!

/me is very confused :-/

Could anyone who was involved please write a short description of what
was changed exactly? I'm only trying to reconstruct the current
situation, not looking for a scapegoat.

Hmm... well, perhaps we can learn something from this accident:

The classic way to avoid the "too many cooks" syndrome would be to
appoint a single official maintainer and make all the change requests go
through him. However, I feel this "solution" would create lots of
critical roles and ultimately defeat our ongoing attempts to
decentralize system administration.

Instead, we shall establish simple procedures to improve sysadmin
coordination and communication. For example:

1) commit configuration changes in git along with a short description
   of what was done and why. We already have repositories for /etc and
   also and we could create more repos as needed;

2) write a short report for systems@ when we make substantial changes
   to a service;

3) write or update the wiki documentation for important sysadm
   procedures such as installing a new instance of a service

Use your common sense to decide what needs to be documented and how much
detail is needed. At all costs, we want to avoid putting too much
bureaucratic burden on volunteers because it's the most effective way to
make them look for something more exciting to do.

We could save time by coalescing steps (1) and (2): all we need to do is
enabling a post-commit hook in the repositories that would send patches
to systems-logs@ . We need to be extra careful not to expose passwords
in this way. Any volunteers to write and test this procedure?

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/