Re: [Sugar-devel] changes in trac and others
On 04.10.2010, at 12:56, Tomeu Vizoso wrote: Note that mentioning it in #sugar is not enough +1 - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] changes in trac and others
Excerpts from Tomeu Vizoso's message of Mon Oct 04 12:56:24 +0200 2010: A change that I think can be made without asking first is the addition of the 1.0 milestone, but I think we still need to agree on the meaning of moving a ticket to that milestone. You are faster to complain than I can write an email about the change. :-P The addition of Seeta-specific fields needs to be discussed before, because we have other organizations working together in Sugar Labs and some amount of coordination is needed. +1, I was quite surprised by it, but expected it to have been agreed upon by Aleksey, Simon and you. Seems that wasn't the case. It's OK if Seeta uses our bug tracker (especially since inter-bugtracker integration is still in its infancy in general and not supported by Trac at all AFAICT), but it would have been nice to discuss this on systems@ first (or at least announce it). Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] TamTamEdit, TamTamJam, etc.
Hi, does any of the TamTam tools provide a possibility to save the musical output, so that it can be edited/used in an other application? Kind of a Save as menu? (.ogg/.mp3/.wav etc.)? I couldn't find this feature neither in documentation nor in the tools themselves. Thanks for your help, Tom Staubitz ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Record activity. Adjusting the input level.
Hi, is there a way to adjust the input level of audio recordings in Record, according to the volume of the sound source? I read every piece of documentation I found[1][2]. It does not look as if this is supported? Thanks for your help, Tom Staubitz [1] http://activities.sugarlabs.org/en-US/sugar/addon/4081 [2] http://wiki.laptop.org/go/Record ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] changes in trac and others
Hi, have seen that recently some changes have been made to trac outside the normal adding of users and components. I would like to request that when making those changes, that the list was notified, if the change is presumed uncontroversial. If the change has a broader effect (such as adding a field), please ask in sugar-devel first for opinions. A change that I think can be made without asking first is the addition of the 1.0 milestone, but I think we still need to agree on the meaning of moving a ticket to that milestone. The addition of Seeta-specific fields needs to be discussed before, because we have other organizations working together in Sugar Labs and some amount of coordination is needed. Note that mentioning it in #sugar is not enough because not everybody is always present and because the channel is not logged. For other services, please notify the list as well when your changes will affect the other people's work. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Turtle Blocks-99
Activity Homepage: http://activities.sugarlabs.org/addon/4027 Sugar Platform: 0.82 - 0.90 Download Now: http://activities.sugarlabs.org/downloads/file/27057/turtle_art-99.xo Release notes: This is the first post-0.90 release of Turtle Blocks. Enhancements: * reskinable turtle (#2353) lets you use the turtle as a sprite for creating animations * updated Tamil, Spanish (#2359), and German translations * expandable two-argument blocks (#2330, #2336) for enhanced block layout * added locale support for decimal_point rendering, e.g., 1,0 in DE, 1.0 in US Bug fixes: * setxy honors pen up/pen down (#2358) * updated samples to take advantage of #2330 and removed extra turtles * removed import numpy to fix #2313 and #2314 * fixed rounding error that prevented max value from being returned by random (#2380) Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Advice request: XO sound recording
Excerpts from James Simmons's message of Mon Oct 04 01:28:03 +0200 2010: There is a chapter called Fun With The Journal which has examples of listing out Journal entries. What you need to do is figure out what the MIME type of the Ogg entries in the Journal are and write code to list them. Then you can put the entries in a GTK table and select them from there. Just a word of caution: While access to the data store is unrestricted because nobody got around to implement the access controls, this won't be the case forever. In general you should only assume that you have access to the entry belonging to the currently running activity session (P_DOCUMENT [1,2]). The Object Chooser is a powerbox [3] that will grant your activity access to an additional entry selected by the user (and only that one entry, nothing else). While activities can request additional permissions [4] only certain combinations will be granted automatically. In particular listing data store entries is mutually exclusive with network access [5]: We solve this by allowing programs to request read-only permissions for one type of document (e.g. image, audio, text, e-mail) at installation time, but making that permission (#P_DOCUMENT_RO) mutually exclusive with asking for any network access at all. A photo viewing program, in other words, normally has no business connecting to the Internet. While the user can explicitly grant activities additional permissions, we should be careful not to train them to do this for a significant number of activities as it would make the system pointless and vulnerable to the attacks we're trying to guard the users against (e.g. [6]). Sascha [1] http://wiki.laptop.org/go/OLPC_Bitfrost#P_DOCUMENT:_file_store_service [2] http://dev.laptop.org/git/security/tree/bitfrost.txt#n874 [3] http://en.wikipedia.org/wiki/File_dialog#Powerbox [4] http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API#Permissions_Declarations [5] http://wiki.laptop.org/go/OLPC_Bitfrost#P_DOCUMENT_RO [6] http://wiki.laptop.org/go/OLPC_Bitfrost#Compromising_privacy_2 -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Proposal of dotted activity version number
The current activity version scheme does only allow the use of integer numbers. This has the issue that doing a bug fix release for an older activity version gets rather complicated. People have been planning for that in advance and reserved numbers for such a purpose in order to overcome that short coming. Furthermore, the current scheme does not allow local deployments to release local versions of an activity. Based on the work that has been started in the Dotted Activity Versions feature [1] I want to propose a new scheme that fixes the issues described above. The new version number will consist of N integer numbers separated by dots and a suffix for a local indicator. Activity developers can still use an integer number only, if desired. Valid numbers are: 23 23.2 23.2.5 23.2.5-peru 23.2.5-uru The internal representation will be a string instead of an int and we will add means to validate and compare the versions. What do others think about this approach? Packagers? We must limit the number of integer digits allowed? Regards Gonzalo [1] http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Replacing Illegal character ':' in username (SL #2152)
Bernie, On Mon, Oct 4, 2010 at 12:53 AM, Bernie Innocenti ber...@codewiz.orgwrote: If you want to ensure that I read a message intended for me, you'd better keep me on cc. I don't read every single post sent to sugar-devel. * Sorry. Will follow it from now on. On Sun, 2010-10-03 at 00:12 +0530, Dipankar Patro wrote: I am currently facing some problem with XS setup. I downloaded the image and installed it on VMware. But that did not work. What failed exactly? I am unable to find a way to connect to my network while running XS. I actually installed XS software on VMware under Windows 7, and its showing me CUI. Got totally confused and finally left it. :( Bernie, is there no online school-server available where I can connect to and check? Bernie, Since the school server setup may take up a day or two, I can definitely work on the bug #1976 in the meantime. I will send the patch as soon as it is ready and tested. Thanks. Please make sure that, in the default case when nothing is configured, the behavior on the XO-1 stays the same as before. Findings on Bug #1976: - Initially I was not able to track whether the jabber_server we are setting is actually being set or not. (I am using sugar-emulator in Ubuntu). Thanks to Aleskey who figured out how Sugar is storing info (jabber_server) in a second instance of gconf! - Now, Bernie, I am confused with the bug :(. What are we really trying to remove? It would be great if you could explain the statement: to keep the old behavior, this patch would also need to set the default value of /desktop/sugar/collaboration/jabber_server to schoolserver ^^ Does this mean that I need to set the jabber_server property to schoolserver at the time of first boot? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Trac: added 1.0 milestone
Hi! I just added a 1.0 milestone to Trac and used it for a ticket. The intended meaning is we should change (or at least look at) this before we declare the API 'stable' (whatever that means ;) ). If anyone has a better name for that milestone we can rename it. Similarly, if we decided to call the next release (that would be 0.92) 1.0 because of the API break Gnome forced on us, we can rename it to 2.0. It's only meant to be used for things that affect API, especially activity API. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On Mon, Oct 4, 2010 at 10:27 AM, Gonzalo Odiard gonz...@laptop.org wrote: The current activity version scheme does only allow the use of integer numbers. This has the issue that doing a bug fix release for an older activity version gets rather complicated. People have been planning for that in advance and reserved numbers for such a purpose in order to overcome that short coming. How often is it the case that we wouldn't just want the latest version of an activity to replace a bug-laden older version? Is there a use case? That said, I have no objection to adding dotted version numbers. Furthermore, the current scheme does not allow local deployments to release local versions of an activity. Based on the work that has been started in the Dotted Activity Versions feature [1] I want to propose a new scheme that fixes the issues described above. The new version number will consist of N integer numbers separated by dots and a suffix for a local indicator. Activity developers can still use an integer number only, if desired. Valid numbers are: 23 23.2 23.2.5 23.2.5-peru 23.2.5-uru The internal representation will be a string instead of an int and we will add means to validate and compare the versions. What do others think about this approach? Packagers? We must limit the number of integer digits allowed? Regards Gonzalo [1] http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On 10/04/2010 04:48 PM, Walter Bender wrote: On Mon, Oct 4, 2010 at 10:27 AM, Gonzalo Odiardgonz...@laptop.org wrote: The current activity version scheme does only allow the use of integer numbers. This has the issue that doing a bug fix release for an older activity version gets rather complicated. People have been planning for that in advance and reserved numbers for such a purpose in order to overcome that short coming. How often is it the case that we wouldn't just want the latest version of an activity to replace a bug-laden older version? There are cases where this is not possible. Take Browse as an example. Browse is highly tight to the underlying Sucrose version, hence Browse from 0.90 won't run on 0.84. If one has released Browse version 108 for Sucrose 0.84 and 109 for 0.86 one is in deep trouble if one wants to fix a bug in 0.84. So this is one use case where the extended scheme makes sense. I think it is much more flexible in general, and the good part is that people can still keep on using the integer version number. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Advice request: XO sound recording
://sascha.silbe.org/ http://www.infra-silbe.de/ -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20101004/466091fe/attachment-0001.pgp ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Testing 0.90 on an XO
Hi, I have been doing 0.90-F14 builds for the XO-1 and XO-1.5. You can grab the latest build from [1]. I provide these builds that people that do have XO-hardware can start helping testing 0.90. So far, we did not have much testing yet. We just released 0.90.0 and want to do a bug fix release at the end of the month [2]. So testing and filing good bug reports is highly welcome. Please use these builds only for reporting back 0.90 issues. There are surely issues that are due to integration issues. Leave them for now. When you report bugs at [3] with these builds please set the Version to 0.90 and add the keyword olpc-0.90 to be able differentiate those bugs. A good first start would be to test the Features [4] that have landed in 0.90. Each page does contain a test case. As well the release notes at [5] might be of help. And of course, testing different languages and smoke tests of all different fashions are welcome. Regards, Simon [1] http://dev.laptop.org/~erikos/F14_builds/ [2] http://wiki.sugarlabs.org/go/0.90/Roadmap#Schedule [3] http://bugs.sugarlabs.org [4] http://wiki.sugarlabs.org/go/0.90/Feature_List [5] http://wiki.sugarlabs.org/go/0.90/Notes === Known Issues === Here is a list of current Issues in the builds I have found so far: - Gnome keyring pops up at first start: http://bugs.sugarlabs.org/ticket/2339 --- At least a new behavior, if not fixable it should be documented what to do. - Physics crashes: http://bugs.sugarlabs.org/ticket/2363 --- We had a similar issue in Sugar, the same fix can be applied here. Gary is working on it as I am writing those lines... - Calculate does not start: http://bugs.sugarlabs.org/ticket/2245 --- Version 34 fixes it, will be in a next build - Terminal: Can not scroll when using less: Warning Terminal is not fully functional. On the XO builds I could not edit files with Vi neither which works here ok. There was a new version of VTE in updates-testing (0.26.0-1) but that one did not fix that issue. http://bugs.sugarlabs.org/ticket/2394 --- We have a hint already. - Activity icon not disappearing from the neighborhood view http://bugs.sugarlabs.org/ticket/2389 --- Tomeu has a fix in Gabble and is verifying now if that happens on Salut as well. - Sharing button not updated when resuming a previously-shared activity http://bugs.sugarlabs.org/ticket/2390 --- Tomeu is on that one as well. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On Mon, Oct 04, 2010 at 11:27:36AM -0300, Gonzalo Odiard wrote: The new version number will consist of N integer numbers separated by dots and a suffix for a local indicator. Activity developers can still use an integer number only, if desired. Valid numbers are: 23 23.2 23.2.5 23.2.5-peru 23.2.5-uru The internal representation will be a string instead of an int and we will add means to validate and compare the versions. What do others think about this approach? Packagers? We must limit the number of integer digits allowed? Short version: Gogogo! Slightly longer: Make sure to strictly define the semantics of non-integer parts. It might seem obvious at first - peru being slight fork of micro-version 5. But perhaps sometimes a local branch wants to release a sneak preview, e.g. almost micro-version 6. Should that then be labeled 23.2.6-peru or (since 5-peru is taken already) 23.2.6.peru2? In Debian we allow both letters and digits in all parts, and use special sign ~ to indicate almost and + to indicate just above. And we treat 0 (zero) equal to a missing trailing part. And more nitpicking... I do not, however, recommend you to adopt such complex scheme. I suggest instead (as might actually be what imply by the above summary) that the 3 first parts are strictly digits and intended only for mainline releases, while an optional 4th part is strictly for non-mainline use and allows [a-z0-9] (but nothing else - no dash, underscore, capital or non-ASCII letters, +~ or whatever). Then use simple C locale sort order, and leave it to local branches if they want to use only letters or also leading and/or trailing digits. Enjoy, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
Short version: Gogogo! Thanks! Slightly longer: Make sure to strictly define the semantics of non-integer parts. It might seem obvious at first - peru being slight fork of micro-version 5. But perhaps sometimes a local branch wants to release a sneak preview, e.g. almost micro-version 6. Should that then be labeled 23.2.6-peru or (since 5-peru is taken already) 23.2.6.peru2? In Debian we allow both letters and digits in all parts, and use special sign ~ to indicate almost and + to indicate just above. And we treat 0 (zero) equal to a missing trailing part. And more nitpicking... I do not, however, recommend you to adopt such complex scheme. I suggest instead (as might actually be what imply by the above summary) that the 3 first parts are strictly digits and intended only for mainline releases, while an optional 4th part is strictly for non-mainline use and allows [a-z0-9] (but nothing else - no dash, underscore, capital or non-ASCII letters, +~ or whatever). Then use simple C locale sort order, and leave it to local branches if they want to use only letters or also leading and/or trailing digits. I am planing be more strict: the last part is only [a-zA-Z]* Then the next to 23.2.6-peru will be 23.2.7-peru or 23.2.6.1-peru. The last part does not imply version, only is a helper to the local deployments. Gonzalo Enjoy, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] changes in trac and others
On Mon, Oct 4, 2010 at 8:23 AM, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Tomeu Vizoso's message of Mon Oct 04 12:56:24 +0200 2010: A change that I think can be made without asking first is the addition of the 1.0 milestone, but I think we still need to agree on the meaning of moving a ticket to that milestone. You are faster to complain than I can write an email about the change. :-P The addition of Seeta-specific fields needs to be discussed before, because we have other organizations working together in Sugar Labs and some amount of coordination is needed. +1, I was quite surprised by it, but expected it to have been agreed upon by Aleksey, Simon and you. Seems that wasn't the case. It's OK if Seeta uses our bug tracker (especially since inter-bugtracker integration is still in its infancy in general and not supported by Trac at all AFAICT), but it would have been nice to discuss this on systems@ first (or at least announce it). The SEETA Developer: field might better be adjusted to Developer:, and we could use a convention to tag the developer's name, such as, [SEETA] Ishan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On Mon, Oct 04, 2010 at 12:50:37PM -0300, Gonzalo Odiard wrote: Short version: Gogogo! Thanks! Slightly longer: Make sure to strictly define the semantics of non-integer parts. It might seem obvious at first - peru being slight fork of micro-version 5. But perhaps sometimes a local branch wants to release a sneak preview, e.g. almost micro-version 6. Should that then be labeled 23.2.6-peru or (since 5-peru is taken already) 23.2.6.peru2? In Debian we allow both letters and digits in all parts, and use special sign ~ to indicate almost and + to indicate just above. And we treat 0 (zero) equal to a missing trailing part. And more nitpicking... I do not, however, recommend you to adopt such complex scheme. I suggest instead (as might actually be what imply by the above summary) that the 3 first parts are strictly digits and intended only for mainline releases, while an optional 4th part is strictly for non-mainline use and allows [a-z0-9] (but nothing else - no dash, underscore, capital or non-ASCII letters, +~ or whatever). Then use simple C locale sort order, and leave it to local branches if they want to use only letters or also leading and/or trailing digits. I am planing be more strict: the last part is only [a-zA-Z]* Then the next to 23.2.6-peru will be 23.2.7-peru or 23.2.6.1-peru. The last part does not imply version, only is a helper to the local deployments. So which package will be favored if all of the following are available: 23.2.7 23.2.7-peru 23.2.7-bolivia ? If last part does not imply version, then they are all flavors of same version 23.2.7, yet one might be a bugfix of the other and the third a feature enhancement. Also, if you permit local branches to add more version parts, are they then allowed to add yet another part if need be? What is the strict logic? Or do you not want a strict logic (now, but learn as you move on)? And why a more strict part if it does not imply version? And if it does get used to resolve which of multiple flavors win an election, what is then the sorting algorithm when you permit both capital and lowercase letters? Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] changes in trac and others
On 4 October 2010 17:09, Frederick Grose fgr...@gmail.com wrote: The SEETA Developer: field might better be adjusted to Developer:, and we could use a convention to tag the developer's name, such as, [SEETA] Ishan On a community level, I don't think its right to assign a specific developer to the task. Anyone is welcome to come along and post a patch. If SEETA want to add their internal metadata to the tickets they should use the keywords field. e.g. add keyword seetadev:Ishan Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Advice request: XO sound recording
OK, James and Sasha - then I need additional advice. There is the Object Chooser method, which seems to do what I need (a *general* audio files listing is the appropriate), but is basically inoperable on XO-1. OTOH, the FLOSS manual solution(s) would seem to be considerably more complex (is this correct? Please recall I am a beginning Python programmer.) I am leaning toward investigating James' algorithms except for one fact: I'm not sure that Sugar 0.82 is important to me. Facts: Record on the XO-1 only outputs Ogg Speex audio, and Csound on the XO-1 doesn't accept any kind of Ogg. OTOH, with 0.84 and up, Record outputs Ogg Vorbis and Csound handles the same (on 0.84 Strawberry, a libsndfile update is required). Since Record is the primary way that children will get soundfiles into the Journal, I wonder whether 0.82 is worth the trouble (i.e., the capability of importing child-generated soundfiles). I know I've not mentioned eToys, but I'm not aware that actual soundfile objects that it produces are available through the Journal. (If so, I may need to rethink - and would appreciate comments by Bert.) It is also true that soundfiles in various acceptable formats (WAV, AIFF, VORBIS) can be imported to the Journal via wireless, and presumably accessed there. This *might* be an important capability, even for the XO-1. I *am* convinced that accessing the Journal (nothing else) is the way to go. So? Art Hunkins - Original Message - From: James Simmons nices...@gmail.com To: sugar-devel@lists.sugarlabs.org Sent: Monday, October 04, 2010 10:15 AM Subject: Re: [Sugar-devel] Advice request: XO sound recording Sascha, I fully support the way Activities are not allowed write access to anything but the datastore and their own directories. I even support not being able to list out Journal entries at the same time you do network access. If we get to the point where an Activity cannot list out Journal entries (other than using the Object Chooser) at any time then I've got a beef. I have tried the Object Chooser. In Sugar .82 it had some serious bugs, could not list out only those entries you wanted to look at, and was slow and ugly. A big part of my book is explaining how to write Activities that will run on .82 as well as later versions of Sugar, and there was no way to make the Object Chooser a part of that strategy. As a result I did not discuss it in the book, but did describe how to write your own object choosing code. What I described works well and answers a legitimate need. In my opinion, nothing I am recommending would allow anyone to make a malicious Activity (assuming that listing entries in the data store was blocked during network access). James Simmons Date: Mon, 04 Oct 2010 10:11:00 +0200 From: Sascha Silbe sascha-ml-reply-to-201...@silbe.org Subject: Re: [Sugar-devel] Advice request: XO sound recording To: sugar-devel sugar-devel@lists.sugarlabs.org Message-ID: 1286177910-sup-2...@twin.sascha.silbe.org Content-Type: text/plain; charset=utf-8 Excerpts from James Simmons's message of Mon Oct 04 01:28:03 +0200 2010: There is a chapter called Fun With The Journal which has examples of listing out Journal entries. What you need to do is figure out what the MIME type of the Ogg entries in the Journal are and write code to list them. Then you can put the entries in a GTK table and select them from there. Just a word of caution: While access to the data store is unrestricted because nobody got around to implement the access controls, this won't be the case forever. In general you should only assume that you have access to the entry belonging to the currently running activity session (P_DOCUMENT [1,2]). The Object Chooser is a powerbox [3] that will grant your activity access to an additional entry selected by the user (and only that one entry, nothing else). While activities can request additional permissions [4] only certain combinations will be granted automatically. In particular listing data store entries is mutually exclusive with network access [5]: We solve this by allowing programs to request read-only permissions for one type of document (e.g. image, audio, text, e-mail) at installation time, but making that permission (#P_DOCUMENT_RO) mutually exclusive with asking for any network access at all. A photo viewing program, in other words, normally has no business connecting to the Internet. While the user can explicitly grant activities additional permissions, we should be careful not to train them to do this for a significant number of activities as it would make the system pointless and vulnerable to the attacks we're trying to guard the users against (e.g. [6]). Sascha [1] http://wiki.laptop.org/go/OLPC_Bitfrost#P_DOCUMENT:_file_store_service [2] http://dev.laptop.org/git/security/tree/bitfrost.txt#n874 [3] http://en.wikipedia.org/wiki/File_dialog#Powerbox [4]
[Sugar-devel] [PATCH] Don't emit buddy-removed if we don't know yet its contact-id #2402
Otherwise the owner icon is removed from the neighborhood view
---
src/jarabe/model/neighborhood.py |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/jarabe/model/neighborhood.py b/src/jarabe/model/neighborhood.py
index 478ee46..91dd059 100644
--- a/src/jarabe/model/neighborhood.py
+++ b/src/jarabe/model/neighborhood.py
@@ -283,7 +283,8 @@ class _Account(gobject.GObject):
self.emit('connected')
else:
for contact_handle, contact_id in self._buddy_handles.items():
-self.emit('buddy-removed', contact_id)
+if contact_id is not None:
+self.emit('buddy-removed', contact_id)
for room_handle, activity_id in self._activity_handles.items():
self.emit('activity-removed', activity_id)
--
1.7.2.3
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Don't emit buddy-removed and activity-removed before they have announced #2401
Otherwise we'll get some tracebacks from the listeners of those
signals because they still don't know about those buddies or activities.
---
src/jarabe/model/neighborhood.py |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/jarabe/model/neighborhood.py b/src/jarabe/model/neighborhood.py
index ed23f7f..478ee46 100644
--- a/src/jarabe/model/neighborhood.py
+++ b/src/jarabe/model/neighborhood.py
@@ -858,7 +858,9 @@ class Neighborhood(gobject.GObject):
buddy = self._buddies[contact_id]
del self._buddies[contact_id]
-self.emit('buddy-removed', buddy)
+
+if buddy.props.key is not None:
+self.emit('buddy-removed', buddy)
def __activity_added_cb(self, account, room_handle, activity_id):
logging.debug('__activity_added_cb %r %r', room_handle, activity_id)
@@ -902,7 +904,9 @@ class Neighborhood(gobject.GObject):
return
activity = self._activities[activity_id]
del self._activities[activity_id]
-self.emit('activity-removed', activity)
+
+if activity.props.bundle is not None:
+self.emit('activity-removed', activity)
def __current_activity_updated_cb(self, account, contact_id, activity_id):
logging.debug('__current_activity_updated_cb %r %r', contact_id,
--
1.7.2.3
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Activity permissions, Object Chooser (was: Re: Advice request: XO sound recording)
Excerpts from James Simmons's message of Mon Oct 04 16:15:32 +0200 2010: If we get to the point where an Activity cannot list out Journal entries (other than using the Object Chooser) at any time then I've got a beef. I don't understand the part with the beef, but assume it's meant to mean something like an annoyance. Activities will always be able to request access to the data store that will enable them to list all Journal entries. That request might however be denied depending on what other additional permissions they requested. So a simple Journal browser will always work, but you can't at the same time access the network (and maybe other things if we have a reason to think the combination is dangerous). The purpose is not to annoy anyone, but to protect the user against certain threats. The user herself will always be empowered to grant additional permissions (this is the no lockdown principle [1]). We might also consider blessing certain activities so they always get elevated rights (they would obviously be subjected to stringent requirements including extensive peer review). One example of such a blessing is the Terminal activity in Sugar 0.82. I have tried the Object Chooser. In Sugar .82 it had some serious bugs, could not list out only those entries you wanted to look at, and was slow and ugly. Please verify whether it works well enough now. The next version of Sugar will be based on GNOME 3 (because at least Fedora forces it on us), which means it'll probably be practically impossible to write activities that work with both the next version of Sugar _and_ Sugar 0.82-0.90. So there's no need to avoid something (in activities designed for the next version) just because old versions were buggy. Please let us know about anything re. the activities API that bugs you. Sascha [1] http://wiki.laptop.org/go/OLPC_Bitfrost#Principles -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] any patches for 0.90.1?
Hi, there are several patches awaiting commit and review, but I don't think all of them are intended to go into 0.90. Can submitters reply to their own messages for those that are intended to go in before we branch? Thanks, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] changes in trac and others
Excerpts from Frederick Grose's message of Mon Oct 04 18:09:18 +0200 2010: The SEETA Developer: field might better be adjusted to Developer:, and we could use a convention to tag the developer's name, such as, [SEETA] Ishan What would be the difference between Owner and Developer then? Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Don't emit buddy-removed if we don't know yet its contact-id #2402
On Mon, Oct 4, 2010 at 19:42, Tomeu Vizoso tomeu.viz...@collabora.co.uk wrote:
Otherwise the owner icon is removed from the neighborhood view
Requesting inclusion in 0.90.
Thanks,
Tomeu
---
src/jarabe/model/neighborhood.py | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/jarabe/model/neighborhood.py
b/src/jarabe/model/neighborhood.py
index 478ee46..91dd059 100644
--- a/src/jarabe/model/neighborhood.py
+++ b/src/jarabe/model/neighborhood.py
@@ -283,7 +283,8 @@ class _Account(gobject.GObject):
self.emit('connected')
else:
for contact_handle, contact_id in self._buddy_handles.items():
- self.emit('buddy-removed', contact_id)
+ if contact_id is not None:
+ self.emit('buddy-removed', contact_id)
for room_handle, activity_id in self._activity_handles.items():
self.emit('activity-removed', activity_id)
--
1.7.2.3
___
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] Advice request: XO sound recording
Does anyone have updated experience with Object Chooser on 0.82 and later? Art Hunkins - Original Message - From: James Simmons nices...@gmail.com To: Walter Bender walter.ben...@gmail.com Cc: sugar-devel@lists.sugarlabs.org Sent: Monday, October 04, 2010 11:04 AM Subject: Re: [Sugar-devel] Advice request: XO sound recording Walter, I agree that we can't support .82 forever, but at the time I wrote my Activities (and the book) it was a big issue since that's what most deployments were using. I haven't looked at Object Chooser since then. It may well have improved, but I would guess that it is still slow and ugly and not an adequate replacement for the kinds of things I'm doing in View Slides and Sugar Commander, or what the Library Activity was going to be doing. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Don't emit buddy-removed and activity-removed before they have announced #2401
On Mon, Oct 4, 2010 at 19:44, Tomeu Vizoso tomeu.viz...@collabora.co.uk wrote:
Otherwise we'll get some tracebacks from the listeners of those
signals because they still don't know about those buddies or activities.
Requesting inclusion in 0.90.
Thanks,
Tomeu
---
src/jarabe/model/neighborhood.py | 8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/jarabe/model/neighborhood.py
b/src/jarabe/model/neighborhood.py
index ed23f7f..478ee46 100644
--- a/src/jarabe/model/neighborhood.py
+++ b/src/jarabe/model/neighborhood.py
@@ -858,7 +858,9 @@ class Neighborhood(gobject.GObject):
buddy = self._buddies[contact_id]
del self._buddies[contact_id]
- self.emit('buddy-removed', buddy)
+
+ if buddy.props.key is not None:
+ self.emit('buddy-removed', buddy)
def __activity_added_cb(self, account, room_handle, activity_id):
logging.debug('__activity_added_cb %r %r', room_handle, activity_id)
@@ -902,7 +904,9 @@ class Neighborhood(gobject.GObject):
return
activity = self._activities[activity_id]
del self._activities[activity_id]
- self.emit('activity-removed', activity)
+
+ if activity.props.bundle is not None:
+ self.emit('activity-removed', activity)
def __current_activity_updated_cb(self, account, contact_id, activity_id):
logging.debug('__current_activity_updated_cb %r %r', contact_id,
--
1.7.2.3
___
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] Proposal of dotted activity version number
On Mon, Oct 4, 2010 at 1:37 PM, Jonas Smedegaard d...@jones.dk wrote: On Mon, Oct 04, 2010 at 12:50:37PM -0300, Gonzalo Odiard wrote: Short version: Gogogo! Thanks! Slightly longer: Make sure to strictly define the semantics of non-integer parts. It might seem obvious at first - peru being slight fork of micro-version 5. But perhaps sometimes a local branch wants to release a sneak preview, e.g. almost micro-version 6. Should that then be labeled 23.2.6-peru or (since 5-peru is taken already) 23.2.6.peru2? In Debian we allow both letters and digits in all parts, and use special sign ~ to indicate almost and + to indicate just above. And we treat 0 (zero) equal to a missing trailing part. And more nitpicking... I do not, however, recommend you to adopt such complex scheme. I suggest instead (as might actually be what imply by the above summary) that the 3 first parts are strictly digits and intended only for mainline releases, while an optional 4th part is strictly for non-mainline use and allows [a-z0-9] (but nothing else - no dash, underscore, capital or non-ASCII letters, +~ or whatever). Then use simple C locale sort order, and leave it to local branches if they want to use only letters or also leading and/or trailing digits. I am planing be more strict: the last part is only [a-zA-Z]* Then the next to 23.2.6-peru will be 23.2.7-peru or 23.2.6.1-peru. The last part does not imply version, only is a helper to the local deployments. So which package will be favored if all of the following are available: 23.2.7 23.2.7-peru 23.2.7-bolivia ? No one. If Peru want a package to update 23.2.7, can create 23.2.7.1-peru or 23.2.8-peru The reason is, we don't want use this part to set the order in the update. We have groups of activities anyway, but if a user want to upgrade manually a activity from other place can do it. If last part does not imply version, then they are all flavors of same version 23.2.7, yet one might be a bugfix of the other and the third a feature enhancement. Also, if you permit local branches to add more version parts, are they then allowed to add yet another part if need be? What is the strict logic? Or do you not want a strict logic (now, but learn as you move on)? And why a more strict part if it does not imply version? And if it does get used to resolve which of multiple flavors win an election, what is then the sorting algorithm when you permit both capital and lowercase letters? Sorry, strictest. The idea is not take in account the last part in the compute of the order of the versions. I have excluded the numbers to do it more evident. Capital and lowercase are the same, but we can limit if it's a problem. We are changing from a integer scheme for activities. I don't want over complicate it, and assure the versions can be mapped to packages if necesary. Regards Gonzalo Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCgAGBQJMqgLcAAoJECx8MUbBoAEh9HQP/0PsZp7WxO5CXm28tqSe/kMu 9kRZsVuG9ZmFgPQx6kTfYY8eGlyZWs6o+0HqsASjR+4BRs/l8eniiNwZR1ueR0mf 3nFG3sgtV00TcA26uQaIZjrLRPRihUOk92+HhPNwe+HMKVKA/tDPOzFg4xfBvDrD nyQmbD7U1EKC/uJHHTiyUnt8cclkrUKjmG6cYQnbCub5zkJu+2L4ydhAvp2ah8Eh gxHrRd6I/D9T9AW1wbh/RBvXxn3a8gLcpZLN6wbexIN/iUQy5mbieituFaiIf4/z il/9wVYYnSca4g6eFyBSS9JWOiss2C/xdJddrt+10bbY9g3gHLxg9/i6jZqCMfye 8tpap6dwLHYf/lY9Mr/dcrBXy7qzwD2W8y0dxfzt32b+7ZPFhv+efgxab5FNnzI3 rXfxF88T7gdwuX/2oJv/SLoavxHyitY41Ol3T/A82TYl7tDNS65LfBn6NDJCcM/z XeVTxf2fcqWPvd4/cpGPsQ8KKS+SHPZNCmjb9fLVi58kEB35mD5H42dOPebGgJqF zWg6eozDWi9JsEe3E6XBwdRB2ae92TRsehC0lsZUOz7qDOkXR02cPbk0TQlFR5oM rqWchP4//VlXQQJAze+KybGfO2eM+69uYAz9MXzFPGggv1/N25ey29iwMANi/s58 qeCsdjpSi2G5YZSASoLz =1b9O -END PGP SIGNATURE- ___ 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] Proposal of dotted activity version number
Hi Gonzalo and others, I suspect we talk past each others. But let's just leave it at that. Good luck with the proposal! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Advice request: XO sound recording
Excerpts from Art Hunkins's message of Mon Oct 04 19:33:19 +0200 2010: There is the Object Chooser method, which seems to do what I need (a *general* audio files listing is the appropriate), but is basically inoperable on XO-1. The Object Chooser is hardware agnostic. What leads you to believe it doesn't work on XO-1? Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Advice request: XO sound recording
What made me think that Object Chooser was not feasible in 0.82? This comment from a recent email of James Simmons (which I'm sure you read): I have tried the Object Chooser. In Sugar .82 it had some serious bugs, could not list out only those entries you wanted to look at, and was slow and ugly. A big part of my book is explaining how to write Activities that will run on .82 as well as later versions of Sugar, and there was no way to make the Object Chooser a part of that strategy. I gather you don't agree? Art Hunkins - Original Message - From: Sascha Silbe sascha-ml-reply-to-201...@silbe.org To: sugar-devel sugar-devel@lists.sugarlabs.org Sent: Monday, October 04, 2010 2:53 PM Subject: Re: [Sugar-devel] Advice request: XO sound recording ___ 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] Advice request: XO sound recording
Excerpts from Art Hunkins's message of Mon Oct 04 21:10:02 +0200 2010: What made me think that Object Chooser was not feasible in 0.82? Ah, you seem to equate XO-1 with Sugar 0.82. That's an incorrect assumption, in both directions: Debian Lenny ships Sugar 0.82 and many XO-1s now run Sugar 0.84 [1] or 0.88 [2]. For your activity it seems like concentrating on more recent versions of Sugar makes more sense, to avoid the considerable trouble you encounter with Sugar 0.82. Spend your time by making your activity more awesome instead, giving deployments yet another reason to upgrade to a better version of Sugar. Sascha [1] http://wiki.laptop.org/go/Release_notes/10.1.2 [2] https://wiki.sugarlabs.org/go/Dextrose signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Advice request: XO sound recording
Art, Getting a list of Journal objects that have the MIME types you want is simple. Putting this data into a table requires a fair amount of code. It isn't difficult code, but there is a lot of it. If you just want to get one entry from the table the Object Chooser would be less work for you. The downside is that older versions of Sugar don't let you restrict what you're seeing, plus there is a bug where when the dialog first opens it shows items that are in the Journal AND on the SD card (if you have one). It looks like it's supposed to just show the Journal objects, but it shows both. It's a hard bug to describe. You have to click on the icon for the SD card, then click back on the Journal icon to see just Journal objects. The XO-1 can run newer versions of Sugar than .82, and it looks like more of them will be doing that soon. Using the Object Chooser doesn't necessarily mean it won't work on an XO-1. The reason I gave up on this dialog was that it wasn't doing what I wanted for View Slides, which was to browse through a list of images, view them, and add them to a slide show. That kind of interaction would be slow and painful with the Object Chooser. In your case it might be just fine. I guess a future version of my book will have to discuss the Object Chooser. James Simmons On Mon, Oct 4, 2010 at 12:33 PM, Art Hunkins abhun...@uncg.edu wrote: OK, James and Sasha - then I need additional advice. There is the Object Chooser method, which seems to do what I need (a *general* audio files listing is the appropriate), but is basically inoperable on XO-1. OTOH, the FLOSS manual solution(s) would seem to be considerably more complex (is this correct? Please recall I am a beginning Python programmer.) I am leaning toward investigating James' algorithms except for one fact: I'm not sure that Sugar 0.82 is important to me. Facts: Record on the XO-1 only outputs Ogg Speex audio, and Csound on the XO-1 doesn't accept any kind of Ogg. OTOH, with 0.84 and up, Record outputs Ogg Vorbis and Csound handles the same (on 0.84 Strawberry, a libsndfile update is required). Since Record is the primary way that children will get soundfiles into the Journal, I wonder whether 0.82 is worth the trouble (i.e., the capability of importing child-generated soundfiles). I know I've not mentioned eToys, but I'm not aware that actual soundfile objects that it produces are available through the Journal. (If so, I may need to rethink - and would appreciate comments by Bert.) It is also true that soundfiles in various acceptable formats (WAV, AIFF, VORBIS) can be imported to the Journal via wireless, and presumably accessed there. This *might* be an important capability, even for the XO-1. I *am* convinced that accessing the Journal (nothing else) is the way to go. So? Art Hunkins ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity permissions, Object Chooser (was: Re: Advice request: XO sound recording)
Sascha, Sorry about the idiomatic English. It sounds like what you're saying the permissions would be and what I would have them be are close enough, maybe exactly the same. If I am correct then we could make a version of the Library Activity that allows a user to specify a list of Journal objects he is willing to share by selecting them from the Journal, then share just those objects, as long as he doesn't make the list and share the objects at the same time. Does that sound accurate? It seems to me that this was what Library version 2 was supposed to do. I agree on GNOME 3 making it impossible to write an Activity that works on new and older versions of Sugar. For awhile there you could write an Activity that made the most of whatever version of Sugar was available and I strove to do that and teach others how to do that. I'll have to take another look at the Object Chooser. It won't be for awhile; the latest version of Linux I run at home is Fedora 11 and I have other work I want to finish before I upgrade. James Simmons Date: Mon, 04 Oct 2010 19:48:14 +0200 From: Sascha Silbe sascha-ml-reply-to-201...@silbe.org Subject: [Sugar-devel] Activity permissions, Object Chooser (was: Re: Advice request: XO sound recording) To: sugar-devel sugar-devel@lists.sugarlabs.org Message-ID: 1286212879-sup-8...@twin.sascha.silbe.org Content-Type: text/plain; charset=utf-8 Excerpts from James Simmons's message of Mon Oct 04 16:15:32 +0200 2010: If we get to the point where an Activity cannot list out Journal entries (other than using the Object Chooser) at any time then I've got a beef. I don't understand the part with the beef, but assume it's meant to mean something like an annoyance. Activities will always be able to request access to the data store that will enable them to list all Journal entries. That request might however be denied depending on what other additional permissions they requested. So a simple Journal browser will always work, but you can't at the same time access the network (and maybe other things if we have a reason to think the combination is dangerous). The purpose is not to annoy anyone, but to protect the user against certain threats. The user herself will always be empowered to grant additional permissions (this is the no lockdown principle [1]). We might also consider blessing certain activities so they always get elevated rights (they would obviously be subjected to stringent requirements including extensive peer review). One example of such a blessing is the Terminal activity in Sugar 0.82. I have tried the Object Chooser. In Sugar .82 it had some serious bugs, could not list out only those entries you wanted to look at, and was slow and ugly. Please verify whether it works well enough now. The next version of Sugar will be based on GNOME 3 (because at least Fedora forces it on us), which means it'll probably be practically impossible to write activities that work with both the next version of Sugar _and_ Sugar 0.82-0.90. So there's no need to avoid something (in activities designed for the next version) just because old versions were buggy. Please let us know about anything re. the activities API that bugs you. Sascha ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
I agree with the proposal. -- James Cameron System Test Coordinator One Laptop per Child ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On Mon, Oct 4, 2010 at 5:25 PM, James Cameron qu...@laptop.org wrote: I agree with the proposal. +1 -- 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
Re: [Sugar-devel] Proposal of dotted activity version number
On 5 October 2010 10:25, James Cameron qu...@laptop.org wrote: I agree with the proposal. -- James Cameron System Test Coordinator One Laptop per Child I tentatively agree. My strong preference is for Activities to rapidly increase their integer numbers, rather than creating a complex tree of point releases. My feeling is that a tree of three or more levels deep adds complexity to new Learners. It goes against the 'low floor, no ceiling' philosophy by requiring that Learners learn a new counting system, on top of integer increments. It also adds to the pressure to maintain several versions of the software concurrently. While I agree that maintainence releases are important, I would prefer that community etiquette is developed that discourages version numbers that look like 2.4.12. Developers should be strongly encouraged to migrate to a new integer release when practical. Most activities are quite discrete. They tend not to add many features once they have reached a desired level of maturity. Tim. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Unwanted characters in mail to sugar-devel list serv when sending patch.
On 10/02/2010 02:54 AM, Shanjit Singh Jajmann wrote: I just made patch for Issue 2324, and forwarded it to the list. A lot of unwanted characters seem to have crept in, however when i send it to my inbox, or any other, no such thing happens. Could some pointers be provided to resolve this problem? What sort of characters are you talking about? -- ╒═╕ │Luke Faraone ╭Debian / Ubuntu Developer╮│ │http://luke.faraone.cc╰Sugar Labs, Systems Admin╯│ │PGP: 5189 2A7D 16D0 49BB 046B DC77 9732 5DD8 F9FD D506 │ ╘═╛ signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Testing 0.90 on an XO
Please use these builds only for reporting back 0.90 issues. There are surely issues that are due to integration issues. Leave them for now. How do I tell what an integration issue is? Do you only want bugs on new features and not regressions? Tony ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Testing 0.90 on an XO
On 05/10/2010, at 12:39 PM, fors...@ozonline.com.au wrote: How do I tell what an integration issue is? There's a few methods, but they require either experience or knowledge of the software components and how they interface. If in doubt, just log the issue and let the developer analyse and reject it. -- James Cameron System Test Coordinator One Laptop per Child ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On 5 Oct 2010, at 00:30, James Cameron qu...@laptop.org wrote: On 05/10/2010, at 10:16 AM, Tim McNamara wrote: My strong preference is for Activities to rapidly increase their integer numbers, rather than creating a complex tree of point releases. My feeling is that a tree of three or more levels deep adds complexity to new Learners. It goes against the 'low floor, no ceiling' philosophy by requiring that Learners learn a new counting system, on top of integer increments. Tentative +0.25 as well if others think this is really, really necessary - but I personally never want to have to maintain two or more versions of any activity (what the doted version support is really all about). When we hit a show stopping api break, consider the last working release the end of line, or upgrade to a newer Sugar that is supported by a newer activity release. Yes. Better than the current situation though. Only if the change does not break 0.82 and 0.84 integer based updates/installs. Or are we saying that as of 0.92 every activity will have to fork and break with past versions of Sugar anyway? If so I can see little motivation as an activity developer to move to 0.92 for quite some time, who wants to write activities almost no deployment will use for likely 6 to 18 months at best? I guess if this is the case, moving to a new versioning scheme in 0.92 is fine even if it breaks 0.82 and 0.84, as no activities for 0.92 will run anyway on past Sugar versions :( Ideally, instead of presenting a version number to a learner, a graph describing the history of the activity source and dependencies could be displayed. Ouch. Alternatively, separate the Learner visible numbering from the software release numbering, and leave the visible numbering within the scope of a deployment. Then one deployment's Browse-190 may be different to another deployment's Browse-190. Oh please for the love of maintenance no, how will we ever deal with bug reports. If a deployment decides to fork, say Physics, and introduces their own bugs and/or breaks Journal entry compatibility by adding some feature, I do not want to burn up any more of my life dealing with tickets reported with ambiguous version information, it's bad enough dealing with tickets from folks not testing against the current release. Regards, --Gary -- James Cameron System Test Coordinator One Laptop per Child ___ 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
