[cc += dfarning, alsroot, syst...@] 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/ _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep