Re: [Sugar-devel] Code Review process changes
On Fri, Apr 30, 2010 at 22:00, Bernie Innocenti ber...@codewiz.org wrote: El Fri, 30-04-2010 a las 10:49 +0200, Tomeu Vizoso escribió: What's the problem with plain email reviews that we're trying to solve with bug trackers and fancy review tools? It's useful to have the patches tracked and related to the bug report. Yes, but not all patches are related to bug reports. I'd like a fast path for simple patches that took 1 minute to write and shouldn't take more than 1 minute to review and apply. With a smooth development process, such trivial patches dominate the overall volume of patches. But if the overhead gets too high, they're lost. Are you saying you cannot have a fast track that keeps patches tracked? In GNOME and Freedesktop it takes a few seconds to submit a patch for review to bugzilla: $ git bz file my-product/some-component HEAD I don't have time to waste discussing how our system could be completely different. After we changed to use the same system as Linux, someone would start complaining we should switch to Mozilla's. Changing or refining the development process is as important as writing code. Now we have a problem that code already written is stuck because the current process is failing. I'm obviously ok with refining, I just don't have time energy nor time to switch to a completely different system now. For the sake of keeping some focus in this discussion, seems like you are saying that we cannot get enough resources to keep a process in which maintainers play a strong role. I actually think we can and I'm proposing a plan in another thread to get those resources. If SLs decides not to push for such a plan, then I would agree with you in that we need to make without maintainers. On IRC, you said you were in favor of doing reviews directly on the mailing list. Everyone else agreed, so I this part of the change should be already settled. It should be obvious, but just in case, we still need to agree on specific changes to the process and need to update the documentation in the wiki before we start using any different process than what we have documented now. We have a system modelled after GNOME's and it used to work when we had maintainers, and of course it works for the dozens of modules in GNOME and Freedesktop. Sure, we can make changes to adapt to the specifics of Sugar's community, but that request for change should come from the maintainers, who are the ones that will be most directly affected by them. The difference between us and GNOME seems to be in the availability of maintainers. Why it seems like that to you? For example, PyGObject is minimally maintained right now and it's affecting our work on Python 3. People are frustrated about it and we are discussing what to do, but I have still to hear from anyone that the maintainer-based system must be dropped. We are asking downstreams to contribute back with resources so PyGObject is maintained and next week I will be flying to the Ubuntu Developer Summit for that. Resourcing maintenance is often a problem, but somehow, not all projects think it's a good idea just to do without it. Maybe they have a reason? We can go back to the GNOME model when we'll have solved this issue, but at this time this model is clearly not working for us. Good luck with that experiment, I unfortunately won't have time to spend on it. Can peers also approve patches? If so, then I think we've already solved our issue. Well, we don't have enough peers, many of the listed them are not active any more. Having unresponsive people listed as maintainers/peers creates a false expectation. Let's remove those that did not post to the list or Trac over the last 2 months. We can quickly add them back if they come back. Sounds good to me, any volunteer to go through the list and propose the changes? Being so tightly coupled, these 4 modules should probably share the same set of maintainers and peers. That doesn't match my actual experience maintaining Sugar. You are guessing about what some people have actually experienced, please stop doing that. I'm not guessing. I've actually heard this complaint from several people who shall speak up for themselves publicly if they want to. This is the first item in Michael's experimental fork of Sugar lists as the first item: You are guessing because I doubt you have heard that complaint from anybody who has _maintained_ sugar (please read my words with more attention before replying). * combines all six of the sugar, sugar-toolkit, sugar-base, sugar-artwork, sugar-datastore, and sugar-presence-service repos into a single repo [1], So I'm certainly the only one who thinks that the current shredding of Sugar into 6 projects sucks. I'd be curious to know: who actually likes it this way and why? We need to split them conceptually because are different things. Having each of those conceptual units in their own repo with their own
[Sugar-devel] Sugar Digest 2010-05-03
==Sugar Digest== 1. I have fallen way behind in my blogging about Sugar Labs: the combination of too much travel and too much time consumed with repairing my house from flood damage has taken its toll. I'll try to touch on a medley of topics today, referring to various email threads on the lists for more details. (Also, the 'o' key on my keyboard has become flaky—please forgive me any typs.) Perhaps the most exciting news over the past few weeks has been the numerous announcements about One Laptop per Child programs sprouting up around the world. There was an announcement of a significant program in the Middle East [http://www.itworld.com/hardware/106222/un-buy-50-olpc-laptops-palestinian-children]; an initiative in East Africa [http://news.bbc.co.uk/2/hi/technology/10091177.stm]; and when I heard him speak in Miami last week, the president of Honduras, Porfirio Lobo Sosa, spoke about one laptop per child as a legacy he wants to leave for his country. In every case, these are Sugar-based initiatives. It is invigorating to see this steady increase in the application of our efforts to provide great learning opportunities for children. (Kudos to Sean Daly and the Marketing Team for their efforts in getting the word out.) The Sugar-on-a-Stick team is very close to releasing Mirabelle, which is based on Fedora 13 and Sugar 0.88. It is an exciting release because it is both a great effort in terms of content and process. There has been a productive dialog between the packaging team, the developers, testers, and the user community; as a result, we are converging on a more sustainable process and we are better meeting the needs of our users. Many thanks, especially to Peter Robinson, Tom Gilliard, Caryl Bigenho, Mel Chua, James Cameron, Frederick Grose, and Sebastian Dziallas. The Paraguay team is wrapping up their work on porting Fedora 11/Sugar 0.84 to the XO 1.0 hardware. This is important because it will allow deployments to migrate there installed base of machines to the same system being deployed on the XO 1.5 machines, making the overall support and maintenance problem more tractable. The team has also backported a number of bug fixes and features, such as 3G support, needed by deployments. It is a great example of downstream working with upstream. 2. Dogi (Stefan Unterhauser), Adam Holt, and I were in Rochester this week for a series of events at RIT: the OLPC Users Group Meeting; the Dean's Lecture Series (I talked about why learning is so important; [http://www.ustream.tv/recorded/6561388 video]); and the Imagine RIT Innovation Festival. Our host was Stephen Jacobs. We spent some quality time with his students, whom are in project teams, developing two Sugar Activities: OVC (a video chat system being developed in collaboration with the National Institute for the Deaf), and Fortune Hunter, an adventure game geared towards 4th Grade mathematics. The great thing about the program at RIT is the way in which the student projects are being integrated into the global Sugar initative. I've asked Steve to share his secret sauce with other universities so that the model can spread. One concrete outcome of the visit is the establishment of a Sugar Story Team. Remy D of the RIT Storytelling Team has volunteered to lead the effort. Another tangible outcome is that three of the servers donated to Sugar Labs from the Wikipedia Foundation have a new home at RIT. Dogi worked with Steve's students to bring them up to speed on how to maintain the servers. 3. The Sugar Oversight Board had an opportunity to meet face to face, along with about 10 community members whom happened to be in the Cambridge area. In addition to breaking bread together, we discovered that we had consensus regarding the on-going trademark debate. We'll be discussing and voting on the final wording of the policy next time we meet in IRC and will be summarizing (a) how the decision was made; (b) why it was made; (c) what alternatives were considered; (d) how it fits in with the Sugar Labs mission; (e) how it impacts the Sugar; and (f) how it impacts the Sugar community. Stay tuned. 4. There has been a renewed and intense discussion about maintenance over the past few weeks. (The topic is an important one both to Sugar Labs and our downstream partners.) Our developer and release teams have been striving towards a set of well-documented procedures for making Sugar a project with continuity, with an adequate progression in stability and new features and with a development process that gives them some control. You can follow the latest thread of the discussion [http://lists.sugarlabs.org/archive/iaep/2010-April/010740.html]. === Help wanted === 5. We are seeking to revitalize the deployment team and as a consequence, we are seeking community leaders who can play a role in organizing meetings on a regular basis. It is not necessary to be fluent in all of the issues, rather, we need someone who will help shepard the various parties into
[Sugar-devel] [ASLO] Release Turtle Blocks-87
Activity Homepage: http://activities.sugarlabs.org/addon/4027 Sugar Platform: 0.82 - 0.88 Download Now: http://activities.sugarlabs.org/downloads/file/26893/turtle_art-87.xo Release notes: As of Version 87, Turtle Art will be known as Turtle Blocks. There is a new, mini version of Turtle Art that will be known as Turtle Art. (The mini version more directly parallels the Java version of Turtle Art maintained by Brian Silverman. We agreed that it made sense to use the same name for the versions that were most similar and to use a new name, Turtle Blocks, for the version with more advanced features.) Note that projects are interchangeable between the two versions and that project code updates will continues without the need to change anything on the user side. 87 * added fill block * added gray block * fixed typo in sample code * added mouse support to sample code (See http://tonyforster.blogspot.com/2010/03/mouse-support-in-turtleart.html) 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] [DESIGN] Default ad-hoc networks
On 04/27/2010 08:54 AM, Simon Schampijer wrote: Hi, olpc has decided to present ad-hoc networks like they did with mesh networks: three icons in the neighborhood view representing ad-hoc networks with the channels 1, 6, 11. This should preserve the workflow previously introduced and ease the use of ad-hoc networks. More details for the reasoning can be found in [1]. I think this is a great idea and should maybe be adopted by the upstream development, too. So here is what we found out so far: - 3 icons in the neighborhood view representing the 3 channels - we would need three different icons allowing to differentiate the different channels (an interesting idea is here [3]) - those icons should show the status like the Access Point icons does (connected/unconnected) - if someone clicks on one of the icons he joins a possible existing networks or creates a new network - a badge could indicate if a network is already 'active' created by someone else - naming: so far we decided to not name the networks mesh networks to avoid confusion, some voted for 'local network' some for 'our network', others, votes? - the option to create adhoc networks should be removed from the frame device to avoid confusion What do people think about that? Can the design team help to make this happen? Regards, Simon [1] http://lists.laptop.org/pipermail/devel/2009-December/026831.html [2] http://dev.laptop.org/ticket/9845 [3] http://lists.laptop.org/pipermail/devel/attachments/20100422/d9d33027/attachment-0001.png http://lists.laptop.org/pipermail/devel/2010-April/028315.html As a follow up I put on my designers hat and created the icons myself (based on the maya numerals), screenshot attached. What is missing is a badge to indicate if the network is active (someone has created the adhoc network already). Any good ideas how that badge could look like? Naming: Any ideas, comments about the naming of the networks? 'Local network or our network, other ideas? Thanks, Simon attachment: maya_numerals.png___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Default ad-hoc networks
On Mon, May 3, 2010 at 11:32 AM, Simon Schampijer si...@schampijer.dewrote: On 04/27/2010 08:54 AM, Simon Schampijer wrote: ... What is missing is a badge to indicate if the network is active (someone has created the adhoc network already). Any good ideas how that badge could look like? Shouldn't ad-hoc network icons be gray if empty/inactive and colored by the creator's Sugar Learner colors once created? If the creator's beacon stops, then subsequent beaconer's colors might be adopted (if you want to extract that information)[1]. Although, the color change may be the source of some confusion. --Fred [1] http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg07668.html ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Default ad-hoc networks
frederick wrote: On Mon, May 3, 2010 at 11:32 AM, Simon Schampijer si...@schampijer.dewrote: On 04/27/2010 08:54 AM, Simon Schampijer wrote: ... What is missing is a badge to indicate if the network is active (someone has created the adhoc network already). Any good ideas how that badge could look like? Shouldn't ad-hoc network icons be gray if empty/inactive and colored by the creator's Sugar Learner colors once created? If the creator's beacon stops, then subsequent beaconer's colors might be adopted (if you want to extract that information)[1]. Although, the color change may be the source of some confusion. why would anyone care who created an ad-hoc network? by their nature (from a user's perspective) they're anonymous, especially in this case, where their names (as i understand it) are pre-configured. paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Default ad-hoc networks
On Mon, May 3, 2010 at 1:18 PM, Frederick Grose fgr...@gmail.com wrote: Shouldn't ad-hoc network icons be gray if empty/inactive +1, with the following qualifier: there's a small risk that it may get confusing with our convention of gray-is-not-a-search-result and colored by the creator's Sugar Learner colors once created? As Paul points out, ad-hoc networking infrastructure won't care (nor tell) who's the creator, and that's a feature: if the creator walks away/shutsdown/runs our of battery, the network keeps working. cheers, 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
Re: [Sugar-devel] [DESIGN] Default ad-hoc networks
On Mon, May 3, 2010 at 2:32 PM, Paul Fox p...@laptop.org wrote: frederick wrote: On Mon, May 3, 2010 at 11:32 AM, Simon Schampijer si...@schampijer.de wrote: On 04/27/2010 08:54 AM, Simon Schampijer wrote: ... What is missing is a badge to indicate if the network is active (someone has created the adhoc network already). Any good ideas how that badge could look like? Shouldn't ad-hoc network icons be gray if empty/inactive and colored by the creator's Sugar Learner colors once created? If the creator's beacon stops, then subsequent beaconer's colors might be adopted (if you want to extract that information)[1]. Although, the color change may be the source of some confusion. why would anyone care who created an ad-hoc network? by their nature (from a user's perspective) they're anonymous, especially in this case, where their names (as i understand it) are pre-configured. Perhaps I'm confused by the situation? With XO-1 mesh networks, the Neighborhood view would show 3 mesh network icons, all in the Sugar learner's color, plus any access points in various colors. One would have to hover over a network to see its channel or name. The 3 mesh networks could not be distinguished by passive observation. Once a populated network is joined, Sugar learners could see any Neighborhood Activities and associated learners and proceed to participate. It is proposed that the ad-hoc network icons distinguish themselves in 2 ways. First, are they populated? This allows one to join a populated network versus an empty one, or one where you are the only member. Second, of multiple networks (Neighborhoods), which might I want to join? Here, the color of the creator or successor is a hint, but a Neighborhood name would be best. This relates to Simon's second question. If they all have the same name, that is less useful than if the creator or a successor could supply a useful name. --Fred ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Default ad-hoc networks
On 05/03/2010 09:18 PM, Frederick Grose wrote: On Mon, May 3, 2010 at 2:32 PM, Paul Foxp...@laptop.org wrote: frederick wrote: On Mon, May 3, 2010 at 11:32 AM, Simon Schampijersi...@schampijer.de wrote: On 04/27/2010 08:54 AM, Simon Schampijer wrote: ... What is missing is a badge to indicate if the network is active (someone has created the adhoc network already). Any good ideas how that badge could look like? Shouldn't ad-hoc network icons be gray if empty/inactive and colored by the creator's Sugar Learner colors once created? If the creator's beacon stops, then subsequent beaconer's colors might be adopted (if you want to extract that information)[1]. Although, the color change may be the source of some confusion. why would anyone care who created an ad-hoc network? by their nature (from a user's perspective) they're anonymous, especially in this case, where their names (as i understand it) are pre-configured. Perhaps I'm confused by the situation? With XO-1 mesh networks, the Neighborhood view would show 3 mesh network icons, all in the Sugar learner's color, plus any access points in various colors. One would have to hover over a network to see its channel or name. The 3 mesh networks could not be distinguished by passive observation. Once a populated network is joined, Sugar learners could see any Neighborhood Activities and associated learners and proceed to participate. It is proposed that the ad-hoc network icons distinguish themselves in 2 ways. First, are they populated? This allows one to join a populated network versus an empty one, or one where you are the only member. Second, of multiple networks (Neighborhoods), which might I want to join? Here, the color of the creator or successor is a hint, but a Neighborhood name would be best. This relates to Simon's second question. If they all have the same name, that is less useful than if the creator or a successor could supply a useful name. --Fred I compare the adhoc networks with a channel. So nobody owns (create it, at least not visible to the user). Those channels are always present, just a question if anyone is listening or not and if I tune in and listen. We show a different icon when we are connected, on which channel we are listening. The badge I talked about in the mail would indicate someone is already listening on that channel. I don't think it is absolutely necessary and might add more confusion. The color, hmmm. As color is something important in the sugar user interface we have to be careful with it's use. I would go with drawing the icons in the color of the user. Definitely not use the color of the creator and transfer it to all the listeners. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Default ad-hoc networks
On Mon, May 3, 2010 at 3:44 PM, Simon Schampijer si...@schampijer.de wrote: The color, hmmm. As color is something important in the sugar user alternative ideas: - single-vs-double-line for the circle's border - continuous vs dotted line for the circle's border - make the bg colour of the icon transparent (or equal to the bg color of the neighbourhood canvas) 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
Re: [Sugar-devel] [DESIGN] Default ad-hoc networks
On Mon, May 03, 2010 at 01:18:12PM -0400, Frederick Grose wrote: If the creator's beacon stops, then subsequent beaconer's colors might be adopted (if you want to extract that information)[1]. The current beaconer identity is not available from the network stack ... and there's a chance that it would change to the second node that joins a network, and not remain the first node ... and it would shift and change as RF conditions vary ... movement of user's body, vibration of building ... ;-) -- 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] Contextual video assistance
I was watching this video and thought that it makes a lot of sense to have this feature in Sugar http://www.autodeskresearch.com/publications/toolclips#video Thoughts ? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Contextual video assistance
On Mon, May 3, 2010 at 8:12 PM, Mohan Raj R mohanraj@gmail.com wrote: I was watching this video and thought that it makes a lot of sense to have this feature in Sugar http://www.autodeskresearch.com/publications/toolclips#video Thoughts ? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Raul did something similar for Turtle Art (without the video, although it would be easy enough to add that functionality). We ended up moving the hints to the toolbar because they tended to get in the way otherwise. But perhaps a better algorithm for fading would have helped. Maybe Raul's glue could be packaged in a way such that any activity could import it. -walter -- 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] Code Guidelines L10N
Hi all, Am seeking clarification on coding style, notably the use of trailing white space punctuation. import gettext as _ ... _(Enter your name: ) = Generally used _(Enter your name)+: = Best for translators, slower to run, readability decreases _(Enter your name%s) % (: ,) = Avoids concat, readability low Trailing white space punctuation marks can be irritating to deal with. As a translator, it's hard to know the significance of the white space without context if you notice it. When the translator interprets things incorrectly, the reader then experiences the irritation. I've looked through the Code Guidelines[1], but can't see any reference the appropriate way to use gettext -Tim [1] http://wiki.sugarlabs.org/go/Development_Team/Code_Guidelines ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Code Guidelines L10N
Is the colon and whitespace used in all locales? (I'm only familiar with mine, and I'd expect other locales would have other ways to separate question from answer). -- 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] [ASLO] Release XaoS-4
Activity Homepage: http://activities.sugarlabs.org/addon/4299 Sugar Platform: 0.82 - 0.88 Download Now: http://activities.sugarlabs.org/downloads/file/26896/xaos-4.xo Release notes: Fixed fullscreen mode in 0.86+ Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
