[IAEP] ASLO updates
Updates have been made to ASLO, I'm sure there are display bugs floating around because a lot of the code was changed. Please take a few minutes to test it out: http://activities-testing.sugarlabs.org/en-US/sugar/ If you're an activities developer, please check out the developers hub to check for errors (btw, I haven't made all of the branding changes yet, please just check for display errors): http://activities-testing.sugarlabs.org/en-US/developers Thanks, Josh ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] ASLO updates
[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
Re: [IAEP] ASLO updates
On Thu, Oct 15, 2009 at 02:42:15AM -0400, Bernie Innocenti wrote: [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. Thats intended to be so, activities-devel is just mysql copy of activities, I thought, it shouldn't affect activities-devel testing(but you can create new activity/version and it should be downloaded). also noticing that there's still a copy of the activities in the old location, and it is also bigger by 40MB! Thats because /srv/www-sugarlabs/activities/files contains some tmp directory, it shouldn't affect .xo downloading. /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. We just tried to utilize AMO feature when it lets user download public .xos from mirror sources and from files/ for other cases. Recently all .xo were downloaded from files/(even after creating symlink in /upload to files/).. and it was done from several attempts. For now we have two independent sources for .xo downloads: * /srv/www-sugarlabs/activities/files for not public activities and for 30min age public activities * mirrored /upload/activities for all public activities, after making new .xo public, ASLO uploads it to /upload/activities 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; Yeah, for now, ASLO configs are stored only in ~activities/site/app/config 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? Well, we don't need such ASLO specific administration 24x7, most of time it could be just regular file-permissions/apache/etc administration. -- Aleksey ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] ASLO updates
El Thu, 15-10-2009 a las 07:34 +, Aleksey Lim escribió: We just tried to utilize AMO feature when it lets user download public .xos from mirror sources and from files/ for other cases. Recently all .xo were downloaded from files/(even after creating symlink in /upload to files/).. and it was done from several attempts. Hmm... I'm not sure Mirrorbrain would still work if you symlink away from the /srv/upload directory where it is active. To check, use wget on one of the URLs: you should see a 302 redirect before the download starts. Btw, we should start to get psychologically ready to move aslo to beamrider in the future or, better, cluster it on both machines. 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? Well, we don't need such ASLO specific administration 24x7, most of time it could be just regular file-permissions/apache/etc administration. Ok. For now we'll limit it to /etc only. -- // 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
[IAEP] ASLO updates
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/ Thanks, Josh ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
