Re: [Sugar-devel] SOAS questions
-Original Message- From: sugar-devel-boun...@lists.sugarlabs.org [mailto:sugar-devel-boun...@lists.sugarlabs.org] On Behalf Of Peter Robinson Sent: Monday, 22 November 2010 8:32 p.m. To: David Leeming Cc: Sugar devel Subject: Re: [Sugar-devel] SOAS questions On Mon, Nov 22, 2010 at 1:27 PM, David Leeming wrote: > Hello, > > > > I have questions about the latest release of SOAS. Are these observations > unusual or do others see these issues? > > > > (a) eToys does not start up properly. On start up a garbled view of the > animated car is displayed, and then it wont shut down. I also experienced > this with Mirabelle > I've not seen this problem but then prior to release we didn't see too > many people actually test anything and report bugs so we could fix it > before release. OK, I am trying to establish if it is just me. But can't see how. I have downloaded the SOAS4 iso and installed and everything else is working. I have booted (the SOAS) on several PC laptops and it's the same. I am wondering why others don't also see this happening. > (b) A popup appears about a password for a keyring just after Sugar has > started up > Known problem. See numerous discussions about this on the SoaS mailing > list (probably the best location to ask SoaS questions btw). > In regard to (a) I tried to erase the activity and load an early version, > but there erase function seems to have been moved (which I think is a good > idea). Can anyone refer me please? > How did you try to 'erase' it? All SoaS activities are rpm based so > you need to use yum/rpm based commands to add/remove etc. I looked for the erase option when right clicking on it, as one would do with activities on the XO-1 in previous times. So now we just use Terminal? OK by me. Will this allow me to erase eToys completely and then reinstall an earlier version, to investigate my first problem as above? Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Bundle format
On Mon, 2010-11-22 at 10:53 -0500, C. Scott Ananian wrote: > (oh, and the .zip file already has a checksum, it's not clear why > you'd need another one.) Ah, cool... but I guess it's not a cryptographically secure one, right? Plus, I was thinking... shouldn't we support a bundle format with better compression than zip? My favorite pick would be tar + xz, but if we want to retain the file-by-file accessibility of zip, 7z would also work well. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Extending activity microformat spec to include optional olpc_activity_size
On Mon, 2010-11-22 at 10:51 -0500, C. Scott Ananian wrote: > I avoided doing this in the original specification because I meant the > microformat to be human-writable, and I didn't expect humans to be > able to reliably update these fields correctly. The field is optional, though. > Besides, the size can be ascertained with an HTTP HEAD request, which > takes very little bandwidth. Yes, but it introduces latency proportional to the number of activities. Lots of latency from schools in deployments. > Checksum should also be HTTP ETag. Again, less than 100 bytes. > I believe that my original implementation > did both of these optimizations, although I wouldn't be surprised if > some servers didn't properly support HTTP HEAD and/or ETag. But I > believe it is the server which should be fixed in that case. Hmm... I'm not sure this approach could be made to work beyond simple caching proxies. For example, ASLO delegates downloads to a CDN based on HTTP redirects to mirrors (some of which are nearby deployments). With a well-defined digest on content we can reliably identify alterations along the distribution chain. If the update page were on https with a certificate signed by the deployment, we could ensure secure distribution of activities. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
On Mon, 2010-11-22 at 08:25 -0500, C. Scott Ananian wrote: > Random thoughts, not terribly connected: > > 1) agree with developers != designers. It's like developers != > release managers. We developers can often play at being a designer > (or a release manager), but we've got bad tendencies that sneak in, > just because we "know too much" or "know what's hard" or just start > thinking about how to code something instead of how to *use* > something. It's fine to use developers as short-term stand-ins for an > empty slot, but we should keep in mind the dangers and compromises > involved. > > 2) That's not to say that a lot of the basic HIG work can't be done by > a developer -- or a teacher, or *anyone*, really. There's a lot of > "don't want to touch that" paralysis that we should try to get over. > Step 1 of a HIG update could be to import the HIG into a more > appropriate non-wiki tool, or to radically restructure how it is kept > on the wiki to make it more of a living document, and/or to figure out > how versioning should work. Step 2 is probably to go through and > red-line the existing document to describe how (and why) the existing > implementation doesn't currently match the design -- with maybe a > rough idea of whether its the design or the implementation that's "at > fault". Both of these things don't actually need a designer, they > really need *time*. A large "design team" composed mostly of folks > without design training can still be of great ongoing assistance with > these "paperwork" tasks. Progress can/should be made independent of > finding the one perfect dictator. > > 3) I see a little bit of buck-passing going on, as a third-party > observer. It seems like the real reason for a 3-person committee is > that no one wants to actually step up and take on the responsibility > of UX lead. Unfortunately, lack of clearly defined responsibility is > the crux of the problem you're trying to solve, so I'm not certain > that splitting the horcrux is part of the solution. Maybe it would be > help to identify a single dictator and lieutenants (rather than the > committee-of-3) with hat-passing as necessary -- so, for example, we > can have 4 (!) design leads, but each one is ultimate dictator for one > week a month. That reduces time commitment without diluting > buck-stopping responsibility. > > 4) Agreed with the general sentiment that the best shouldn't obstruct > the good. Even with the concerns I stated above about > designers!=developers, having someone step up and actually start > cleaning up the UX docs (and/or organizing the UX patch queue) is > probably the most important thing. Dictatorship may (or may not) > naturally evolve from this; if Walter and/or OLPC are going to find > the perfect UX Design Dictator candidate in 2 months (say) then > consider what you can do in the meantime to pave the way for the > Messiah's arrival. > --scott I basically agree with everything you wrote. Sorry for posting just for stating this, but I couldn't think of anything else to add. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH 13/21 v2 sugar-toolkit] pylint cleanup: remove unused imports
On Fri, Nov 19, 2010 at 05:40:52PM +0100, Sascha Silbe wrote: > Signed-off-by: Sascha Silbe Reviewed-by: James Cameron -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH 05/21 v2 sugar-toolkit] PEP8 cleanup: fix whitespace around operator
On Fri, Nov 19, 2010 at 05:20:29PM +0100, Sascha Silbe wrote: > Signed-off-by: Sascha Silbe Reviewed-by: James Cameron -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH 03/21 v2 sugar-toolkit] PEP8 cleanup: ensure lines are shorter than 80 characters
On Fri, Nov 19, 2010 at 04:35:52PM +0100, Sascha Silbe wrote: > Caught by PEP8. This is important for Sugar because the XO has a small screen > where long lines would make the code hard to understand (because you need to > constantly scroll horizontally). > > Signed-off-by: Sascha Silbe Reviewed-by: James Cameron -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Messages notification
Hi Martin, Just wanted to give you a heads up that I have a slightly different design coming together for notifications. After further, more detailed, work the frame corner notification history palette idea is not coming together so well. I've switched to mockups that actually badge the existing icons in the frame, and add the notification messages to the end of their existing pop-up palettes. It holds truer (I think) to the original HIG and previous mockups of Eben's intent for notifications. I'll try and get the set of new images uploaded to the wiki later this week for folks to review. Regards, --Gary On 17 Nov 2010, at 19:17, Martin Abente wrote: > Change the "want" for "need" and we have: > > "When there is something they _need_ to know" > > And that is exactly the same reason why we are already using the Icon > notifications and the same reason why we are already using Alert widgets all > over sugar (outside activities), and there are still more cases that we don't > do because we simply don't have this feature fully implemented yet. > > That's all i got. > > Abrazos, :) > > On Wed, Nov 17, 2010 at 3:27 PM, Martin Langhoff > wrote: > On Wed, Nov 17, 2010 at 1:10 PM, David Farning wrote: > > This patch has a place in Dextrose. Dextrose is looking at the > > question, "How can we provide support staff the necessary information > > to effectively fix and/or report problems to a higher level of service > > and support?" > > Let's not jump to conclusions. > > Can this be limited to... when the user _wants_ it? > > > > > m > -- > martin.langh...@gmail.com > mar...@laptop.org -- School Server Architect > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] bundlebuilder does not install mimetypes.xml and associated icon #2262
As we do create the ActivityBundle in the config of the bundlebuilder we can use the code from the activitybundle as well to install the mime type. --- src/sugar/activity/bundlebuilder.py |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/sugar/activity/bundlebuilder.py b/src/sugar/activity/bundlebuilder.py index d9dd96d..5f32477 100644 --- a/src/sugar/activity/bundlebuilder.py +++ b/src/sugar/activity/bundlebuilder.py @@ -274,6 +274,8 @@ class Installer(object): shutil.copy(source, dest) +self.config.bundle.install_mime_type(self.config.source_dir) + def cmd_dev(config, args): '''Setup for development''' -- 1.7.2.3 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Extending activity microformat spec to include optional olpc_activity_size
(oh, and the .zip file already has a checksum, it's not clear why you'd need another one.) --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Extending activity microformat spec to include optional olpc_activity_size
On Mon, Nov 22, 2010 at 9:37 AM, Bernie Innocenti wrote: > On Mon, 2010-11-22 at 07:23 +, Aleksey Lim wrote: >> You can try microformat ASLO updater from >> http://activities-testing.sugarlabs.org/services/micro-format.php?name=fructose > > Nice! I'm not sure about the size in KB... bytes would be more natural > for machine parsing, but kilobytes look better in formatted HTML. I avoided doing this in the original specification because I meant the microformat to be human-writable, and I didn't expect humans to be able to reliably update these fields correctly. Besides, the size can be ascertained with an HTTP HEAD request, which takes very little bandwidth. Checksum should also be HTTP ETag. Again, less than 100 bytes. I believe that my original implementation did both of these optimizations, although I wouldn't be surprised if some servers didn't properly support HTTP HEAD and/or ETag. But I believe it is the server which should be fixed in that case. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Extending activity microformat spec to include optional olpc_activity_size
On Mon, 2010-11-22 at 07:23 +, Aleksey Lim wrote: > You can try microformat ASLO updater from > http://activities-testing.sugarlabs.org/services/micro-format.php?name=fructose Nice! I'm not sure about the size in KB... bytes would be more natural for machine parsing, but kilobytes look better in formatted HTML. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
(apologies for not having the time to make these messages shorter) Another way of thinking of this problem might be as civics-style separation of powers. Given that the problem is (simplified) "UX design compromised by developers" (wrong target users, implementing the easiest thing, whatever) -- how are we to guard against this? Any solution will necessarily "slow development". That needs to be acknowledged as a cost. One solution might be to have a monthly "UX oversight board" meeting. For proper separation of powers, no member of the board may have a patch up for review by the board (or they must recuse themselves). Board candidates should also be chosen based on their resumes, not just because "we think they could be convinced to serve". I suggest that it would be easier to fill the board if you keep the workload as light as possible. Therefore you could have a (large?) "design team" group whose job was *not* to make design decisions, but rather to facilitate the work of the oversight board. The board's work would be easy if it had a nice agenda for their meeting (which they didn't have to prepare themselves!) listing each patch/bug up for review, summarizing discussion pro/con, with relevant screenshots/video. The board could meet at a scheduled time each month (on IRC, or Skype, or videoconference) and (if necessary) voices pro/con the various proposals could show up and argue their case. The "design team" facilitators could then summarize the meeting, prepare minutes, guide the development of revised patches as necessary, etc. Timing/frequency/size of the board could be varied as time goes on based on workload, etc. Regardless of the strawman proposal above, my main point here is to suggest thinking about the role of design as a deliberate frustration of developers -- in the same way that the legislature and courts are a deliberate frustration of the power of the executive. I think this mindset would lead to a very different idea of "Design Dictator" that the one proposed early in this thread -- whose function seemed to be to rubber-stamp/expedite patches, not preserve UX. --scott ps. ...and preserving UX seems orthogonal to the task of "maintaining design documents", which is a separate job description at litl, at least. -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SOAS questions
On Mon, Nov 22, 2010 at 1:27 PM, David Leeming wrote: > Hello, > > > > I have questions about the latest release of SOAS. Are these observations > unusual or do others see these issues? > > > > (a) eToys does not start up properly. On start up a garbled view of the > animated car is displayed, and then it won’t shut down. I also experienced > this with Mirabelle I've not seen this problem but then prior to release we didn't see too many people actually test anything and report bugs so we could fix it before release. > (b) A popup appears about a password for a keyring just after Sugar has > started up Known problem. See numerous discussions about this on the SoaS mailing list (probably the best location to ask SoaS questions btw). > In regard to (a) I tried to erase the activity and load an early version, > but there erase function seems to have been moved (which I think is a good > idea). Can anyone refer me please? How did you try to 'erase' it? All SoaS activities are rpm based so you need to use yum/rpm based commands to add/remove etc. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] SOAS questions
Hello, I have questions about the latest release of SOAS. Are these observations unusual or do others see these issues? (a)eToys does not start up properly. On start up a garbled view of the animated car is displayed, and then it won't shut down. I also experienced this with Mirabelle (b) A popup appears about a password for a keyring just after Sugar has started up In regard to (a) I tried to erase the activity and load an early version, but there erase function seems to have been moved (which I think is a good idea). Can anyone refer me please? David Leeming Solomon Islands Rural Link ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
Random thoughts, not terribly connected: 1) agree with developers != designers. It's like developers != release managers. We developers can often play at being a designer (or a release manager), but we've got bad tendencies that sneak in, just because we "know too much" or "know what's hard" or just start thinking about how to code something instead of how to *use* something. It's fine to use developers as short-term stand-ins for an empty slot, but we should keep in mind the dangers and compromises involved. 2) That's not to say that a lot of the basic HIG work can't be done by a developer -- or a teacher, or *anyone*, really. There's a lot of "don't want to touch that" paralysis that we should try to get over. Step 1 of a HIG update could be to import the HIG into a more appropriate non-wiki tool, or to radically restructure how it is kept on the wiki to make it more of a living document, and/or to figure out how versioning should work. Step 2 is probably to go through and red-line the existing document to describe how (and why) the existing implementation doesn't currently match the design -- with maybe a rough idea of whether its the design or the implementation that's "at fault". Both of these things don't actually need a designer, they really need *time*. A large "design team" composed mostly of folks without design training can still be of great ongoing assistance with these "paperwork" tasks. Progress can/should be made independent of finding the one perfect dictator. 3) I see a little bit of buck-passing going on, as a third-party observer. It seems like the real reason for a 3-person committee is that no one wants to actually step up and take on the responsibility of UX lead. Unfortunately, lack of clearly defined responsibility is the crux of the problem you're trying to solve, so I'm not certain that splitting the horcrux is part of the solution. Maybe it would be help to identify a single dictator and lieutenants (rather than the committee-of-3) with hat-passing as necessary -- so, for example, we can have 4 (!) design leads, but each one is ultimate dictator for one week a month. That reduces time commitment without diluting buck-stopping responsibility. 4) Agreed with the general sentiment that the best shouldn't obstruct the good. Even with the concerns I stated above about designers!=developers, having someone step up and actually start cleaning up the UX docs (and/or organizing the UX patch queue) is probably the most important thing. Dictatorship may (or may not) naturally evolve from this; if Walter and/or OLPC are going to find the perfect UX Design Dictator candidate in 2 months (say) then consider what you can do in the meantime to pave the way for the Messiah's arrival. --scott ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] [PATCH] Feature Request added : Kill the Mute function by clicking on the speaker icon.
On 11/21/2010 01:20 AM, Bernie Innocenti wrote: On Mon, 2010-11-15 at 11:17 +0100, Simon Schampijer wrote: Yes, I prefer as well the term "remove" over "kill" in commit messages. Please reference as well the ticket if there is one at the end of the commit message (e.g. Remove mute toggle #1234). Can we switch to the convention of adding a short prefix to the bug numbers to disambiguate which tracker they come from? This is what I've been doing in Dextrose for a while: Subject: sl#1234: blah blah blah Subject: olpc#5678: foo bar baz Subject: rh#9012: blah blah blah Yes, that works for me. I even had a guideline written down at some point for commit messages, can't find it at the moment though :/ Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Engineering Team
On 11/20/2010 02:06 PM, Aleksey Lim wrote: On Sat, Nov 20, 2010 at 04:27:49AM +, Martin Dengler wrote: On Sat, Nov 20, 2010 at 02:53:06AM +, Aleksey Lim wrote: Hi all, (Just trying to summarize previous discussions, including recent one on #sugar with some kind of motion) = The problem = [...] = Engineering Team [the solution] = [...] I'm not opposed to the discussion. While we (continue to) have it, am I wrong in thinking the de factor situation is that: - anyone who is allowed push to sugar* repos is allowed to approve and / or push a patch or other code (and is trusted to not push contentious things) The practice was (if got it right), only glucose maintainers (discussing with their peers) might say "please push" http://wiki.sugarlabs.org/go/Development_Team/Release/Modules#Glucose Yes, commit access means that you can do the commit yourself. Not that you commit without review. When Tomeu stepped aside, we have "unmaintained" for sugar. Another important module is maintained by Simon, but he is busy with OLPC work. And this is a typical case. That is why separating the workload makes sense. The idea is having several people who can say "please push" for all glucose modules. Maybe better to have such people per module, but we have only 4 modules (I guess people will manage to work together), moreover there might situations when patches/features affect several core modules eg ds and shell. Actually the previous model was mainly like that. For example as the shell co-maintainer I was as well eligible to give my ok for a push to the shell. Back then when we did the original separation of the work load we just decided on one main maintainer per module and added peers so we were not blocking on one person (someone is on vacation and a new release is needed, someone steps down etc). - people who are not allowed to push to sugar should do this to get code in: http://wiki.sugarlabs.org/go/Development_Team/Code_Review All patch/feature providers need to follow this rule (including glucose maints who need to patch). That was in previous scheme and I think would be useful to keep this way for the new one. Yes, we always reviewed all the patches, including the ones from maintainers. I think this is important and should stay like this. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Eliminate Glucose co-maintainers
On 22 November 2010 12:02, Simon Schampijer wrote: > > On 11/22/2010 03:04 AM, Martin Dengler wrote: >> >> I propose we eliminate "co-maintainers" from Glucose[1] because they >> reduce the responsibility and pressure of a sole maintainer. > > I see it the other way around. Reducing the pressure on a maintainer is a > good thing. If we only have one person doing the work we have a bottle neck. > This person gets tired more quickly. Furthermore we are a volunteer based > open source project. If people step down due to any reasons it is good to > have peers that can take over and that have been involved in the process > before. I agree. Sascha and co-maintain Browse and while it's not ideal (because we both have very little free time) it's still much better than not having any maintenance at all. I don't tend to rely on Sascha doing things because I know he's busy, so if I have time, I just do things. From what I know, he does the same. There's no overlap because everything is open (all patches get ml threads) and it's less likely that at any point in time there's no one available to do some important work. > As example see the localization situation. Sayamindu stepped down (he was the > single coordinator) and we did not know what to do for localization then. > > About responsibility, of course I can only report about my experience from > being a co-maintainer: I don't think I have been caring less about the shell > release just because I have been the co maintainer. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Engineering Team
On 11/22/2010 11:46 AM, James Cameron wrote: On Mon, Nov 22, 2010 at 10:29:32AM +, Daniel Drake wrote: On 22 November 2010 00:02, James Cameron wrote: I don't think this is true. ?Some patches, in particular my network disconnect fix, are in 0.84 but not in trunk. Sounds like an oversight, do you know who committed it? fcb1cec by Sayamindu. The plan was for only upstream stuff: http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg10809.html "There may be exceptions, but in general we'll only be taking patches that are already in master." This was an exception then. Yes, I think this was an exception. OLPCA have been making sure over the last months that all the patches did land in master already. And we reduced as well parts that made it harder to reach those goals (e.g. the new activity version). Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Eliminate Glucose co-maintainers
On 11/22/2010 03:04 AM, Martin Dengler wrote: I propose we eliminate "co-maintainers" from Glucose[1] because they reduce the responsibility and pressure of a sole maintainer. I see it the other way around. Reducing the pressure on a maintainer is a good thing. If we only have one person doing the work we have a bottle neck. This person gets tired more quickly. Furthermore we are a volunteer based open source project. If people step down due to any reasons it is good to have peers that can take over and that have been involved in the process before. As example see the localization situation. Sayamindu stepped down (he was the single coordinator) and we did not know what to do for localization then. About responsibility, of course I can only report about my experience from being a co-maintainer: I don't think I have been caring less about the shell release just because I have been the co maintainer. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Eliminate Glucose co-maintainers
On Mon, Nov 22, 2010 at 02:04:45AM +, Martin Dengler wrote: > Having more than one person making these decisions risks reducing the > responsibility of the sole maintainer to maintain a quality release. > Essentially, it's too easy to leave maintainer work if you think > someone else could be helping you. Agreed. I'm shocked to find that co-maintainership was even happening, and it might go a long way to explain some behaviours. I know that if I had a co-maintainer for some other projects, I'd probably shirk. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] IRC-7 on updated Soas-v3-mirabelle possible Bug?
Any chance of a tar file uploaded to? http://download.sugarlabs.org/sources/honey/IRC/ Peter On Sun, Nov 21, 2010 at 4:45 PM, Fran Rogers wrote: > Should be fixed in a new release I pushed out today (version 8). > -Fran > > On Sat, Nov 20, 2010 at 9:35 PM, James Cameron wrote: >> >> On Sat, Nov 20, 2010 at 01:07:00PM -0800, Thomas C Gilliard wrote: >> > IRC -7 works well as it starts in #sugar. I can talk/receive >> > then I do a /join #sugar-meeting. and it talks >> > I then shut down the activity. >> > I then resume the activity. >> > The 2 tabs show but i get a "*/no one to talk to" message. And though >> > the >> > logins show on IRC on another PC with XChat, My typed messages do not. >> >> Is logged as http://bugs.sugarlabs.org/ticket/2493 >> >> -- >> James Cameron >> http://quozl.linux.org.au/ >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel > > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Engineering Team
On Mon, Nov 22, 2010 at 10:29:32AM +, Daniel Drake wrote: > On 22 November 2010 00:02, James Cameron wrote: > > I don't think this is true. ?Some patches, in particular my network > > disconnect fix, are in 0.84 but not in trunk. > > Sounds like an oversight, do you know who committed it? fcb1cec by Sayamindu. > The plan was for only upstream stuff: > http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg10809.html "There may be exceptions, but in general we'll only be taking patches that are already in master." This was an exception then. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Engineering Team
On 22 November 2010 00:02, James Cameron wrote: > I don't think this is true. Some patches, in particular my network > disconnect fix, are in 0.84 but not in trunk. Sounds like an oversight, do you know who committed it? The plan was for only upstream stuff: http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg10809.html Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Audio tag not wroking in browse
i tested the html files using firefox in gnome but still the same problem occurs. On Mon, Nov 22, 2010 at 11:57 AM, Mike Dawson wrote: > I am gonna do a couple tests with some other versions here to check > their HTML5 support here - I am wondering off the top of my head if > there could also be a strange permission issue in between xulrunner > and rainbow. > > Regards, > > -Mike > > On Mon, Nov 22, 2010 at 9:45 AM, javed khan > wrote: > > i forget to mention, i used the audio tag like this > > > > audio tag is not supported > > > > When i load the page in fedora os (or any other) it works fine, but on XO > it > > show me a black rectangle, if it doesn't support the audio tag then the > page > > should show the message "audio tag is no supported" > > the black rectangle comes usually when it can't find the source file. > > > > On Mon, Nov 22, 2010 at 10:09 AM, javed khan > wrote: > >> > >> i get it from the os#.packages.txt > >> xulrunner-1.9.1.9-1.fc11.i586 > >> xulrunner-python-1.9.1.9-1.fc11.i586 > >> > >> > >> On Sun, Nov 21, 2010 at 4:27 PM, Lucian Branescu > >> wrote: > >>> > >>> It's up to xulrunner (gecko) to support . What version of > >>> xulrunner are you using? > >>> > >>> On Sunday, 21 November 2010 at 09:36, javed khan wrote: > >>> > >>> i checked the html5 audio tag but it is not working, any patch for it > >> > >> > >> -- > >> Javid Alam > >> Software Developer and Technical support Officer OLPC > >> Ministry of Education > >> Kabul Afghanistan > >> contact: +93(0)798123451 > >> alternative email: javid.a...@moe.gov.af > > > > > > > > -- > > Javid Alam > > Software Developer and Technical support Officer OLPC > > Ministry of Education > > Kabul Afghanistan > > contact: +93(0)798123451 > > alternative email: javid.a...@moe.gov.af > > > > ___ > > Sugar-devel mailing list > > Sugar-devel@lists.sugarlabs.org > > http://lists.sugarlabs.org/listinfo/sugar-devel > > > > > -- Javid Alam Software Developer and Technical support Officer OLPC Ministry of Education Kabul Afghanistan contact: +93(0)798123451 alternative email: javid.a...@moe.gov.af ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Pathagar, Library Activity, etc.
Hi James, James Simmons writes: > I think most of you know I wrote a FLOSS Manual called "Make Your Own > Sugar Activities!" What you may not know is that I've been working on > a second FLOSS Manual which is about e-books and Sugar (current title > "E-Book Enlightenment: Reading And Leading With One Laptop Per > Child"). This sounds fantastic, really looking forward reading your book. I've searched in your draft and didn't find any mention of Wikisource. Wikisource is far behind Gutenberg in terms of formats as it only offers HTML (through mediawiki), wikitext and PDF (with some limitations). But maybe it's worth mentionning it along other services. > After working on this book for many months I've come to the conclusion > that the combination of Sugar and free e-books has ENORMOUS potential. I share your point. Once we're done with the various translation projects we have at OLPC France, I would really like us to translate your books into french, when it's available. > http://en.flossmanuals.net/ReadingandSugar/Introduction Thanks and good luck with finalizing this, -- Bastien ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Conozco Alimentos-1
Activity Homepage: http://activities.sugarlabs.org/addon/4324 Sugar Platform: 0.82 - 0.88 Download Now: http://activities.sugarlabs.org/downloads/file/27009/conozco_alimentos-1.xo Release notes: Actividad basada en Conozco Uruguay. Cuenta con el "plato" o "rueda" de la alimentación y consta de preguntas simples para responder sobre los alimentos. Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
