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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel