Re: [sugar] documentation effort for sugar api
On Wed, Jun 4, 2008 at 8:38 PM, Faisal Anwar <[EMAIL PROTECTED]> wrote: > Hello All, > > I'm currently working on creating documentation for the api of several basic > sugar packages. I've started putting some of this work online at > http://wiki.laptop.org/go/Sugar-api-doc. I'm sure that many of you have a > lot of knowledge and experience with different modules in sugar and would > appreciate any help in developing content and ensuring its accuracy. In > particular: > > - if there are any specific tasks associated with a class or package that > aren't documented yet, please feel free to update the wiki yourself or send > me code fragments with clear descriptions. > > - if there is any feedback you have on the organization of the wiki pages as > I've set up or if there is some major package I really need to make sure to > document, please let me know. > > - If there are any issues of accuracy with anything that is on the wiki, > please let me know. > > I've made a point to write and test all sample code that goes up on the > wiki, so it should work with the latest builds of sugar. But, if things do > change with the underlying code or if there are style issues, please do let > me know asap. Also, I found some really good conceptual documentation at > http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines. There are links > to more detailed api documentation pages, but these seem to be empty and in > need of completion. I think it will be good to link the parts of this wiki > that refer to api's to the documentation that I'm helping to set up above. > If you have helped write some of the existing documentation, please do get > in touch! > > Right now, I'm specifically working on documenting the datastore features of > sugar and would especially appreciate an opportunity to talk with someone > with experience with the journal. In addition to email, I should often be on > #sugar and #olpc in IRC under the name fanwar. Hi Faisal, nice to see you are working on this. Any chance we could get a wikibot to update the wiki from the pydocs in the source? If we can manage to do that I will be happy to make an additional effort and help completing the api docs in the sugar code. Feel free to ask when you have doubts. Cheers, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Server-devel] Edublog notes
[ccing sugar] Hi, just some comments: On Thu, Jun 5, 2008 at 5:55 AM, Tarun Pondicherry <[EMAIL PROTECTED]> wrote: > > 1) Provide a client side Browse based WYSIWYG editor that does what the > editor in Moodle Blog does for students to easily create and edit > posts. This version will be sugarized and I think should be modeled > after the interface in the Write Activity. I've done a quick mostly > nonfunctional page to show what I have in mind here: > http://olpc.betarun.com/ui/student_editor.php. This same page will have > a list where students can select where they want to post the blog. > (This may be preset by the teacher so students don't need to select). > When the students click the post option, the blog post will be pushed > into the selected system (Moodle on XS, Blogger.com, Wordpress on a > server). This needs to support image upload, and it would be nice to > support video too. (though video is unlikely to be in this version). > Greg wants this rolled out quickly, which is why we think browse based > is better than Write for the task. (XO images will not need to be > updates) Future XO builds can integrate this portion into Write as > well, but from previous discussion (from back during my SoC app) it > looks like this is outside the scope of the project for Uruguay. Yes, I see three possibilities (two you have already mentioned): - Use libabiword as the editor. Disadvantages: possible loss of fidelity when exporting to html, additions to the API will require a new libabiword rpm to be installed, or ship a private one inside the bundle. Very big advantage: simultaneous edit by several kids. - Use a JS editor inside Browse. There must exist dozens of FOSS solutions, are you sure none of them works for what we are trying to do? - Embed Mozilla's editor inside an activity similarly to how we are embedding the browse in Browse. http://www.xulplanet.com/references/xpcomref/comps/c_editorhtmleditor1.html Not sure which one is the best for you, perhaps going with #2 may be easier? Would be good to leave space for growing later as needed, though. #1 and #3 would give you support for tables. Good luck, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
There is a good chance that this is not be possible without patching xulrunner, which would make me **really** nervous. What you are describing is the old firefox UI, and I *think* they took out the hooks to do that in xulrunner 1.9. Michael, is the target for this feature only G1G1? I think Peru run into this for web mail but I'm not convinced that providing UI to bypass certificates is the right solution there. Kids will be confused, especially if we provide a firefox 3.0 like UI (which seem intentionally designed to make it difficult to accept a custom/invalid certificate). Marco On Thu, Jun 5, 2008 at 7:12 AM, Eben Eliason <[EMAIL PROTECTED]> wrote: > On Thu, Jun 5, 2008 at 12:36 AM, Michael Stone <[EMAIL PROTECTED]> wrote: >> On Tue, Jun 03, 2008 at 11:03:44AM +0200, Marco Pesenti Gritti wrote: >>> * Browser bookmarks and autocompletion. - priority 3 >> >> I'd really like to see some progress on #542/#5534 (deal with >> non-standard SSL certificate authorities). This is going to become a >> bigger and bigger stumbling block the longer we wait. Surely we could >> manage some sort of 'accept this cert' button? (Keep in mind the >> possibility of another G1G1 coming our way in the foreseeable future.) > > I think that a non-modal alert (akin to those used for downloads) > would suffice. Toss up buttons for "view" "cancel" and "accept", with > the first of these presenting a modal alert with the detailed > certificate information, and we'd be set. > > - Eben > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
We probably found a way to just hook up the firefox dialogs, there are some missing bits but it will probably be easier than writing our own certificate manager. You can try it out manually btw by opening this url in a *separate* browser instance: chrome://pippki/content/exceptionDialog.xul Marco On Thu, Jun 5, 2008 at 10:20 AM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > There is a good chance that this is not be possible without patching > xulrunner, which would make me **really** nervous. What you are > describing is the old firefox UI, and I *think* they took out the > hooks to do that in xulrunner 1.9. > > Michael, is the target for this feature only G1G1? > > I think Peru run into this for web mail but I'm not convinced that > providing UI to bypass certificates is the right solution there. Kids > will be confused, especially if we provide a firefox 3.0 like UI > (which seem intentionally designed to make it difficult to accept a > custom/invalid certificate). > > Marco > > On Thu, Jun 5, 2008 at 7:12 AM, Eben Eliason <[EMAIL PROTECTED]> wrote: >> On Thu, Jun 5, 2008 at 12:36 AM, Michael Stone <[EMAIL PROTECTED]> wrote: >>> On Tue, Jun 03, 2008 at 11:03:44AM +0200, Marco Pesenti Gritti wrote: * Browser bookmarks and autocompletion. - priority 3 >>> >>> I'd really like to see some progress on #542/#5534 (deal with >>> non-standard SSL certificate authorities). This is going to become a >>> bigger and bigger stumbling block the longer we wait. Surely we could >>> manage some sort of 'accept this cert' button? (Keep in mind the >>> possibility of another G1G1 coming our way in the foreseeable future.) >> >> I think that a non-modal alert (akin to those used for downloads) >> would suffice. Toss up buttons for "view" "cancel" and "accept", with >> the first of these presenting a modal alert with the detailed >> certificate information, and we'd be set. >> >> - Eben >> > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Server-devel] Edublog notes
On Thu, Jun 5, 2008 at 12:00 PM, Tarun Pondicherry <[EMAIL PROTECTED]> wrote: > > - Embed Mozilla's editor inside an activity similarly to how we are > embedding the browse in Browse. > http://www.xulplanet.com/references/xpcomref/comps/c_editorhtmleditor1.html > > > This looks very promising. The only question I have is how easily I would > be able to make that interface mimic Write and add options to it. (I assume > it would involve changes to Browse or other sugar code). HTML controls > don't display using the sugar interface controls either, so I'm unsure if > this uses them. Well, Browse is a python activity that uses pyxpcom to access the xulrunner functionality from python. Browse uses the browser functionality in xulrunner because it is a browser ;), but your activity could use the html editor functionality that is in xulrunner. You would code the UI in pygtk very similarly to Browse, and just call xulrunner through pyxpcom. > Not sure which one is the best for you, perhaps going with #2 may be > easier? Would be good to leave space for growing later as needed, > though. #1 and #3 would give you support for tables. > > > I'm not sure why #2 (JS editor) would not give me support for tables. > Doesn't Gecko's Midas provide functions to create and modify tables? (I've > done it with editors that run in firefox.) Has that feature been disabled > for some reason? Well, Midas is a html editor implemented in C++ inside xulrunner, right? It can be accessed though js or pyxpcom, so it would work both as #2 and #3. Didn't knew it had support for tables, so I stand corrected. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] review: Daf's view branch
Just few comments:
+class ActivityViewHandler(object):
This class should have member_added and member_removed methods as its
dummy implementation in test_model. A FIXME would be enough for now.
We should probably have a properties_changed method too.
+self.activity_views = {}
A comment explaining the type of the keys and values would be good.
I think you're right, we could stop to support multi actions in queries
(as you already dropped them in views)
In test_model.py you have some: #self.assertEquals(42, context) that
could be removed.
Same for #self.assertEquals([activity2], found_log.
What's your test.py hack? Didn't we already merge the one making error
message more informative?
Except that looks good. I like how you refactored query/view parsing
code and the general design of views.
G.
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] review: Daf's view branch
Le jeudi 05 juin 2008 à 12:40 +0200, Guillaume Desmottes a écrit : > +class ActivityViewHandler(object): > This class should have member_added and member_removed methods as its > dummy implementation in test_model. A FIXME would be enough for now. > We should probably have a properties_changed method too. Btw, activity_found should also send activity properties and participants. I wrote protocol for activity added/removed: http://wiki.laptop.org/go/XMPP_Component_Protocol#Added G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] review: Daf's view branch
Le jeudi 05 juin 2008 à 12:58 +0200, Guillaume Desmottes a écrit : > Le jeudi 05 juin 2008 à 12:40 +0200, Guillaume Desmottes a écrit : > > +class ActivityViewHandler(object): > > This class should have member_added and member_removed methods as its > > dummy implementation in test_model. A FIXME would be enough for now. > > We should probably have a properties_changed method too. > > Btw, activity_found should also send activity properties and > participants. > I wrote protocol for activity added/removed: > http://wiki.laptop.org/go/XMPP_Component_Protocol#Added > ... and each time we send buddies jid (in as participants and in announcements) Gadget should include buddy properties if the user doesn't already have an view with this buddy (as then he already knows about his properties). G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] review: Daf's view branch
Ar 05/06/2008 am 12:40, ysgrifennodd Guillaume Desmottes:
> Just few comments:
>
>
> +class ActivityViewHandler(object):
> This class should have member_added and member_removed methods as its
> dummy implementation in test_model. A FIXME would be enough for now.
> We should probably have a properties_changed method too.
Agreed.
> +self.activity_views = {}
> A comment explaining the type of the keys and values would be good.
>
>
> I think you're right, we could stop to support multi actions in queries
> (as you already dropped them in views)
Ok.
> In test_model.py you have some: #self.assertEquals(42, context) that
> could be removed.
Oops, right.
> Same for #self.assertEquals([activity2], found_log.
>
>
> What's your test.py hack? Didn't we already merge the one making error
> message more informative?
Hmm, I thought we had merged it too. Perhaps I made a mistake.
> Except that looks good. I like how you refactored query/view parsing
> code and the general design of views.
Thanks!
I think the main missing aspects are:
- random views
- correct view size handling
- stress tests (I have some code lying around for older iterations of the
model which we can probably use)
--
Dafydd
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
[sugar] Log-9
Hey, a new version of the log-activity is out! You can download the source from: http://dev.laptop.org/pub/sugar/sources/log-activity/Log-9.tar.bz2 and the bundle from here: http://dev.laptop.org/~erikos/bundles/other/Log-9.xo NEWS: make users non-olpc be able to read the sugar logs - this is important for the activity running on non xo platforms Have fun, Simon ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: | On Thu, Jun 5, 2008 at 12:36 AM, Michael Stone <[EMAIL PROTECTED]> wrote: |> On Tue, Jun 03, 2008 at 11:03:44AM +0200, Marco Pesenti Gritti wrote: |>> * Browser bookmarks and autocompletion. - priority 3 |> I'd really like to see some progress on #542/#5534 (deal with |> non-standard SSL certificate authorities). This is going to become a |> bigger and bigger stumbling block the longer we wait. Surely we could |> manage some sort of 'accept this cert' button? (Keep in mind the |> possibility of another G1G1 coming our way in the foreseeable future.) | | I think that a non-modal alert (akin to those used for downloads) | would suffice. Toss up buttons for "view" "cancel" and "accept", with | the first of these presenting a modal alert with the detailed | certificate information, and we'd be set. I don't understand this at all. If a site offers an invalid/untrusted SSL certificate, it should simply be accepted silently. The user should have the same experience as if the page were not using SSL. We know from experience that users do not know how to interpret the certificate warning, and simply learn to click on the button that allows them to continue. Presenting them with an incomprehensible warning, and then indicating that the connection is secure, is not good security, and not good UI. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhH9NcACgkQUJT6e6HFtqTISgCbBCObRmRVpQHGaoYEf484Qyny c4kAniMlTZgUzUiIc8mOqDtI1BJrZcjm =3UDw -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
Here is a good explanation of how this is handled in Firefox 3.0 (different from both Eben and Benjamin proposal): http://www.dria.org/wordpress/archives/2008/05/06/635/ Marco On Thu, Jun 5, 2008 at 4:14 PM, Benjamin M. Schwartz <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Eben Eliason wrote: > | On Thu, Jun 5, 2008 at 12:36 AM, Michael Stone <[EMAIL PROTECTED]> wrote: > |> On Tue, Jun 03, 2008 at 11:03:44AM +0200, Marco Pesenti Gritti wrote: > |>> * Browser bookmarks and autocompletion. - priority 3 > |> I'd really like to see some progress on #542/#5534 (deal with > |> non-standard SSL certificate authorities). This is going to become a > |> bigger and bigger stumbling block the longer we wait. Surely we could > |> manage some sort of 'accept this cert' button? (Keep in mind the > |> possibility of another G1G1 coming our way in the foreseeable future.) > | > | I think that a non-modal alert (akin to those used for downloads) > | would suffice. Toss up buttons for "view" "cancel" and "accept", with > | the first of these presenting a modal alert with the detailed > | certificate information, and we'd be set. > > I don't understand this at all. If a site offers an invalid/untrusted SSL > certificate, it should simply be accepted silently. The user should have > the same experience as if the page were not using SSL. > > We know from experience that users do not know how to interpret the > certificate warning, and simply learn to click on the button that allows > them to continue. Presenting them with an incomprehensible warning, and > then indicating that the connection is secure, is not good security, and > not good UI. > > - --Ben > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkhH9NcACgkQUJT6e6HFtqTISgCbBCObRmRVpQHGaoYEf484Qyny > c4kAniMlTZgUzUiIc8mOqDtI1BJrZcjm > =3UDw > -END PGP SIGNATURE- > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Thu, Jun 5, 2008 at 10:14 AM, Benjamin M. Schwartz <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Eben Eliason wrote: > | On Thu, Jun 5, 2008 at 12:36 AM, Michael Stone <[EMAIL PROTECTED]> wrote: > |> On Tue, Jun 03, 2008 at 11:03:44AM +0200, Marco Pesenti Gritti wrote: > |>> * Browser bookmarks and autocompletion. - priority 3 > |> I'd really like to see some progress on #542/#5534 (deal with > |> non-standard SSL certificate authorities). This is going to become a > |> bigger and bigger stumbling block the longer we wait. Surely we could > |> manage some sort of 'accept this cert' button? (Keep in mind the > |> possibility of another G1G1 coming our way in the foreseeable future.) > | > | I think that a non-modal alert (akin to those used for downloads) > | would suffice. Toss up buttons for "view" "cancel" and "accept", with > | the first of these presenting a modal alert with the detailed > | certificate information, and we'd be set. > > I don't understand this at all. If a site offers an invalid/untrusted SSL > certificate, it should simply be accepted silently. The user should have > the same experience as if the page were not using SSL. > > We know from experience that users do not know how to interpret the > certificate warning, and simply learn to click on the button that allows > them to continue. Presenting them with an incomprehensible warning, and > then indicating that the connection is secure, is not good security, and > not good UI. Yeah, I prefer this solution, actually; I thought for some reason it wasn't acceptable to some, but maybe I'm wrong. It's also (I'd think) an easier one to implement. What we should focus on instead, if we choose this direction, is providing an indication for secure sites. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Thu, Jun 5, 2008 at 4:24 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: >> We know from experience that users do not know how to interpret the >> certificate warning, and simply learn to click on the button that allows >> them to continue. Presenting them with an incomprehensible warning, and >> then indicating that the connection is secure, is not good security, and >> not good UI. > > Yeah, I prefer this solution, actually; I thought for some reason it > wasn't acceptable to some, but maybe I'm wrong. It's also (I'd think) > an easier one to implement. What we should focus on instead, if we > choose this direction, is providing an indication for secure sites. Does any web browser actually implement that behavior? We should be damn sure that there are no reasons against it if we decide to go down this way... Besides, I don't think there is a way to implement this cleanly with xulrunner. You'd have to do something something really messy like: 1 Load the page. 2 Firefox cancels it and inform us about it. 3 We automatically add an exception to allow the site to load. 4 We reload the page. 5 We show all the sites with a "broken" certificate as unsecure. Honestly the only viable solution (at least on the short time) is to just hook up the firefox UI. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] criticals about missing grandparent when implicitly creating a new style
On Mon, Jun 2, 2008 at 7:20 PM, Owen Taylor <[EMAIL PROTECTED]> wrote: > > On Mon, 2008-06-02 at 08:43 -0700, Tomeu Vizoso wrote: >> Hi, >> >> Sugar is getting the following criticals at startup: >> >> ** (sugar-shell:25941): CRITICAL **: hippo_canvas_context_get_style: >> assertion `HIPPO_IS_CANVAS_CONTEXT(context)' failed >> >> ** (sugar-shell:25941): CRITICAL **: hippo_canvas_style_new: assertion >> `HIPPO_IS_CANVAS_CONTEXT(context)' failed >> >> ** (sugar-shell:25941): CRITICAL **: hippo_canvas_style_set_link_type: >> assertion `HIPPO_IS_CANVAS_STYLE(style)' failed >> >> ** (sugar-shell:25941): CRITICAL **: >> hippo_canvas_style_get_border_width: assertion >> `HIPPO_IS_CANVAS_STYLE(style)' failed >> >> A bit of looking around showed that the problem was with calling >> hippo_canvas_get_width_request on an item still without a grandparent >> context. >> >> Not knowing anything about styles, would the following patch make any >> sense? > > To me, it doesn't really make sense. Until you have a context, a box > doesn't *have* a width request. (For example, the context is needed > to size text.) I see. > Can you fix the code that was calling get_width_request() before > adding the box into a hierarchy? Yup. > (Obviously, having some more informative warnings and more stable > behavior would be good if we decide that calling get_width_request() > at this point is in fact invalid.) Yes, a warning would be nice. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Moving to metacity with composition (was: Preparing for the feature freeze)
For composition to not eat memory (a full frame buffer's worth/activity), the buried windows need to be "unmapped" in X parlance. When a window is unmapped, X can free the contents of the window even when composite is running (IIRC). This may require some work in whatever window manager we decide on. - Jim > > Just for the record, I'm not strongly advocating for composition in > 8.2. I just happen to think that it could bring a lot of value and we > should consider carefully if it's doable or not. -- Jim Gettys <[EMAIL PROTECTED]> One Laptop Per Child ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Pippy-22
Hey, a new version of pippy is out! You can download the source from here: http://dev.laptop.org/pub/sugar/sources/pippy-activity/Pippy-22.tar.bz2 and the bundle from here: http://dev.laptop.org/~erikos/bundles/other/Pippy-22.xo NEWS: Add check to not fail on new gtksourceview2 API - this is needed for the activity to run on non xo platforms Have fun, Simon ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Autonomous system for Sugar development....
I've been chatting with Kim this morning about sugar project hosting... I have several goals here: o something that OLPC can be comfortable depending on (we have currently the strongest dependency on Sugar and put in the most developer resources; this is unlikely to change in the immediate future). Reaching this comfort-level is essential, in my view, toward any successful migration. Today, if we screw up, we screw up and take the biggest hit; to take an external dependency for something as central to OLPC as sugar more than hand waving is essential; concrete plans and people are needed. o disentangling Sugar from operational OLPC services; for example, our developer/activation key distribution facilities are critical operational resources for OLPC. The current organic growth of the systems at OLPC means that we have had to be overly restrictive to access to machine(s) providing community services. This was driven home to me by the extended effort required to integrate Pootle with Git, and having these community services conflated with OLPC operational services being on the same physical systems caused what should have been a straightforward integration problem to become a month long headache. Making a Sugar separation would make our job cleaning up OLPC's system management easier, so we have some incentive to see sugar become administered independently. o enabling the system to be managed independently of OLPC, in particular our operational infrastructure; we are still inadequately staffed to "just do it" trivially, and I don't want promises made that cannot be kept. I also don't want to see future holdups such as happened with Pootle to repeat, as additional services useful to the Sugar project may become needed. Sugar as a project needs to be able to fill its own needs without getting entangled in situations that often come up in an project such as OLPC that now has operational pressures from deployment. And so long as Sugar is entangled with our operational infrastructure, Sugar makes OLPC's system management more difficult. o ensure (at least read-only) mirroring of key information (e.g. wiki, git tree, trac databases etc.) is easily possible, both for redundancy's sake, and for in-country use. There are a number of other related project sites which can/should be used to mirror this way (e.g. freedesktop.org), and countries need to be able to mirror sugar in country. Requirements/possibilities: 1) I think we can likely arrange to host a machine in the MIT co-lo center. It has lots of bandwidth. (last I knew, 5 different long haul carriers @ 1gig/second each touched down there; along with 10 gig up the river to Harvard, BU, etc.). There is precedent for even fully independent open source projects being in the co-lo center (e.g. X.org), that have had ties to MIT. 2) said machine must be fully remotely manageable (the MIT co-lo center has remote hands service if needed, along with professional backup services). 3AM weekend phone calls are for the birds. 3) OLPC might be able to pay for a machine for Sugar, though this isn't a slam dunk or guaranteed. See 4) 4) someone needs to specify exactly what said machine will be (e.g. memory, disk, CPU, dual power supplies, etc.); once I know that, I can see if OLPC might be able to pay for it, if need be, but hand waving doesn't help here. I don't have time to do this research right now. 5) a concrete plan as to how to establish any source repositories from the community web services (which are typically the least secure parts of the services); some virtualization technology is sufficient for this separation, I believe, to start. I still have scars on my back from the freedesktop.org break-in, where it took us 6 weeks (IIRC) to re-verify each and every line of code in that system's project repositories against personal copies people had made. This is essential to enable less paranoia about access for people doing system administration of the web services part of a hosting system. 6) someone to write in blood that said system will be properly backed up (and that backup be tested), and mirrored elsewhere. Freedesktop (Portland) is one option, develer another (Italy) for initial mirroring. A sysadmin team needs to be formed so there is no single point of failure and timely response to issues. 7) I can do the physical installation of said system, if necessary, and get a remote console on the network with your favorite installation DVD installed. But a plan from there needs to be formulated... I'd like to see a credible plan about how said system's software will be installed, by whom, with a sketch of the software configuration. We'd also need a plan for migration of sugar specific activity would take place, without disturbing the current development stream any more than necessary. Acknowledgment of the realities of release schedules is also needed in such plans... And if it feels I'm holding this to a higher standard than the curren
Re: [sugar] Autonomous system for Sugar development....
Rest assured that Sugar Labs has every intention of being "professional" and upholding the highest standards of quality and conduct. -walter On Thu, Jun 5, 2008 at 12:18 PM, Jim Gettys <[EMAIL PROTECTED]> wrote: > I've been chatting with Kim this morning about sugar project hosting... > > I have several goals here: > > o something that OLPC can be comfortable depending on (we have > currently the strongest dependency on Sugar and put in the most > developer resources; this is unlikely to change in the immediate > future). Reaching this comfort-level is essential, in my view, toward > any successful migration. Today, if we screw up, we screw up and take > the biggest hit; to take an external dependency for something as central > to OLPC as sugar more than hand waving is essential; concrete plans and > people are needed. > > o disentangling Sugar from operational OLPC services; for example, our > developer/activation key distribution facilities are critical > operational resources for OLPC. The current organic growth of the > systems at OLPC means that we have had to be overly restrictive to > access to machine(s) providing community services. This was driven home > to me by the extended effort required to integrate Pootle with Git, and > having these community services conflated with OLPC operational services > being on the same physical systems caused what should have been a > straightforward integration problem to become a month long headache. > Making a Sugar separation would make our job cleaning up OLPC's system > management easier, so we have some incentive to see sugar become > administered independently. > > o enabling the system to be managed independently of OLPC, in > particular our operational infrastructure; we are still inadequately > staffed to "just do it" trivially, and I don't want promises made that > cannot be kept. I also don't want to see future holdups such as happened > with Pootle to repeat, as additional services useful to the Sugar > project may become needed. Sugar as a project needs to be able to fill > its own needs without getting entangled in situations that often come up > in an project such as OLPC that now has operational pressures from > deployment. And so long as Sugar is entangled with our operational > infrastructure, Sugar makes OLPC's system management more difficult. > > o ensure (at least read-only) mirroring of key information (e.g. wiki, > git tree, trac databases etc.) is easily possible, both for redundancy's > sake, and for in-country use. There are a number of other related > project sites which can/should be used to mirror this way (e.g. > freedesktop.org), and countries need to be able to mirror sugar in > country. > > Requirements/possibilities: > > 1) I think we can likely arrange to host a machine in the MIT co-lo > center. It has lots of bandwidth. (last I knew, 5 different long haul > carriers @ 1gig/second each touched down there; along with 10 gig up the > river to Harvard, BU, etc.). There is precedent for even fully > independent open source projects being in the co-lo center (e.g. X.org), > that have had ties to MIT. > > 2) said machine must be fully remotely manageable (the MIT co-lo center > has remote hands service if needed, along with professional backup > services). 3AM weekend phone calls are for the birds. > > 3) OLPC might be able to pay for a machine for Sugar, though this isn't > a slam dunk or guaranteed. See 4) > > 4) someone needs to specify exactly what said machine will be (e.g. > memory, disk, CPU, dual power supplies, etc.); once I know that, I can > see if OLPC might be able to pay for it, if need be, but hand waving > doesn't help here. I don't have time to do this research right now. > > 5) a concrete plan as to how to establish any source repositories from > the community web services (which are typically the least secure parts > of the services); some virtualization technology is sufficient for this > separation, I believe, to start. I still have scars on my back from the > freedesktop.org break-in, where it took us 6 weeks (IIRC) to re-verify > each and every line of code in that system's project repositories > against personal copies people had made. This is essential to enable > less paranoia about access for people doing system administration of the > web services part of a hosting system. > > 6) someone to write in blood that said system will be properly backed up > (and that backup be tested), and mirrored elsewhere. Freedesktop > (Portland) is one option, develer another (Italy) for initial mirroring. > A sysadmin team needs to be formed so there is no single point of > failure and timely response to issues. > > 7) I can do the physical installation of said system, if necessary, and > get a remote console on the network with your favorite installation DVD > installed. But a plan from there needs to be formulated... I'd like to > see a credible plan about how said system's software will be installed,
Re: [sugar] Autonomous system for Sugar development....
Assurances are one thing: concrete plans for execution are another Let's get concrete... - Jim On Thu, 2008-06-05 at 12:22 -0400, Walter Bender wrote: > Rest assured that Sugar Labs has every intention of being > "professional" and upholding the highest standards of quality and > conduct. > > -walter > > On Thu, Jun 5, 2008 at 12:18 PM, Jim Gettys <[EMAIL PROTECTED]> wrote: > > I've been chatting with Kim this morning about sugar project hosting... > > > > I have several goals here: > > > > o something that OLPC can be comfortable depending on (we have > > currently the strongest dependency on Sugar and put in the most > > developer resources; this is unlikely to change in the immediate > > future). Reaching this comfort-level is essential, in my view, toward > > any successful migration. Today, if we screw up, we screw up and take > > the biggest hit; to take an external dependency for something as central > > to OLPC as sugar more than hand waving is essential; concrete plans and > > people are needed. > > > > o disentangling Sugar from operational OLPC services; for example, our > > developer/activation key distribution facilities are critical > > operational resources for OLPC. The current organic growth of the > > systems at OLPC means that we have had to be overly restrictive to > > access to machine(s) providing community services. This was driven home > > to me by the extended effort required to integrate Pootle with Git, and > > having these community services conflated with OLPC operational services > > being on the same physical systems caused what should have been a > > straightforward integration problem to become a month long headache. > > Making a Sugar separation would make our job cleaning up OLPC's system > > management easier, so we have some incentive to see sugar become > > administered independently. > > > > o enabling the system to be managed independently of OLPC, in > > particular our operational infrastructure; we are still inadequately > > staffed to "just do it" trivially, and I don't want promises made that > > cannot be kept. I also don't want to see future holdups such as happened > > with Pootle to repeat, as additional services useful to the Sugar > > project may become needed. Sugar as a project needs to be able to fill > > its own needs without getting entangled in situations that often come up > > in an project such as OLPC that now has operational pressures from > > deployment. And so long as Sugar is entangled with our operational > > infrastructure, Sugar makes OLPC's system management more difficult. > > > > o ensure (at least read-only) mirroring of key information (e.g. wiki, > > git tree, trac databases etc.) is easily possible, both for redundancy's > > sake, and for in-country use. There are a number of other related > > project sites which can/should be used to mirror this way (e.g. > > freedesktop.org), and countries need to be able to mirror sugar in > > country. > > > > Requirements/possibilities: > > > > 1) I think we can likely arrange to host a machine in the MIT co-lo > > center. It has lots of bandwidth. (last I knew, 5 different long haul > > carriers @ 1gig/second each touched down there; along with 10 gig up the > > river to Harvard, BU, etc.). There is precedent for even fully > > independent open source projects being in the co-lo center (e.g. X.org), > > that have had ties to MIT. > > > > 2) said machine must be fully remotely manageable (the MIT co-lo center > > has remote hands service if needed, along with professional backup > > services). 3AM weekend phone calls are for the birds. > > > > 3) OLPC might be able to pay for a machine for Sugar, though this isn't > > a slam dunk or guaranteed. See 4) > > > > 4) someone needs to specify exactly what said machine will be (e.g. > > memory, disk, CPU, dual power supplies, etc.); once I know that, I can > > see if OLPC might be able to pay for it, if need be, but hand waving > > doesn't help here. I don't have time to do this research right now. > > > > 5) a concrete plan as to how to establish any source repositories from > > the community web services (which are typically the least secure parts > > of the services); some virtualization technology is sufficient for this > > separation, I believe, to start. I still have scars on my back from the > > freedesktop.org break-in, where it took us 6 weeks (IIRC) to re-verify > > each and every line of code in that system's project repositories > > against personal copies people had made. This is essential to enable > > less paranoia about access for people doing system administration of the > > web services part of a hosting system. > > > > 6) someone to write in blood that said system will be properly backed up > > (and that backup be tested), and mirrored elsewhere. Freedesktop > > (Portland) is one option, develer another (Italy) for initial mirroring. > > A sysadmin team needs to be formed so there is no sin
[sugar] new Journal release v91
Hi, a new release of the Journal has appeared here: https://dev.laptop.org/pub/sugar/sources/journal-activity/Journal-91.tar.bz2 Changelog: - Arabic translations update (Khaled) - Italian translations update (Carlo) - Misc small fixes (Simon and Tomeu) Cheers, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Terminal-12 is out
Hello everyone. A new version (version 12) of Terminal Activity has been released. You can get the sources at http://dev.laptop.org/pub/sugar/sources/terminal-activity/Terminal-12.tar.bz2 -- Changes since the previous version * #5520: Make the activity exit when the user exits the shell. (sayamindu) -- Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Chat-40 released
I have released Chat 40, at the following URLs: http://dev.laptop.org/pub/sugar/sources/chat-activity/Chat-40.tar.bz2 http://dev.laptop.org/~morgan/bundles/Chat-40.xo The changelog from Chat 39 is: * #5767: Use black text on light fill colors (matthias) Regards, Morgan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Sugar mtg minutes, 5th June 2008
Topics * How can we improve the review process? action item: unmadindu/cjb setup review board http://www.review-board.org/ 1. Break your projects into small pieces that can be submitted for review independently. Submit for review as early as possible, by mailing list or review-board site or whatever other mechanism. More specific: * preferred way if possible: 1. code a small part, 2. submit to review, 3. get into joyride, 4. repeat * not talking about: 1. code everything, 2. split in patches, 3. submit 2. If you want testing before review, make a topic build. 3. Some new tools will be needed to make topic builds easier to make. (.img, .rpm, and .deb) * Bundlebuilder: how to create tarballs best to not include unintentional files. We agreed to use an explicit MANIFEST but to provide tools to build it automatically. homunqlus is going to work on a patch for this. We need to try and freeze bundlebuilder to be able to include Develop in 8.2. * How to announce a new release of an activity best? Deferred to next week meeting and we will open an email thread in the meantime ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] etoys-3.0.2007 / etoys-activity-82
Freshly released: http://dev.laptop.org/pub/sugar/sources/etoys/etoys-3.0.2007.tar.gz http://dev.laptop.org/pub/sugar/sources/etoys-activity/etoys-activity-82.tar.gz or, if you prefer ready-to-use bundles: http://etoys.laptop.org/rpms/etoys-3.0.2007-1.noarch.rpm http://etoys.laptop.org/rpms/Etoys-82.xo NEWS * more translatable phrases * minor tile fixes - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Web-89
Good evening, tomeu did an amazing job and hacked away those last two weeks on Browse and so we have a great new version with many improvements! You can download the source from here: http://dev.laptop.org/pub/sugar/sources/web-activity/Web-89.tar.bz2 and the bundle from here: http://dev.laptop.org/~erikos/bundles/Web-89.xo NEWS: 89 * Make the object chooser transient on the activity window. (tomeu) 88 * Add Edit toolbar (tomeu) * Add Follow link item to link palette (tomeu) * Add palette for images (tomeu) * Add a simple palette for links with an option to copy to the clipboard (tomeu) Have fun, Simon ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] documentation effort for sugar api
Hi Tomeu, Thanks for your email and willingness to help. I'm prioritizing getting something similar to the java almanac up and running, but if I can get a substantial body of how to's completed in the next couple of weeks, then I will prioritize working on the wikibot. Best, Faisal On Thu, Jun 5, 2008 at 3:26 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > On Wed, Jun 4, 2008 at 8:38 PM, Faisal Anwar <[EMAIL PROTECTED]> wrote: > > Hello All, > > > > I'm currently working on creating documentation for the api of several > basic > > sugar packages. I've started putting some of this work online at > > http://wiki.laptop.org/go/Sugar-api-doc. I'm sure that many of you have > a > > lot of knowledge and experience with different modules in sugar and would > > appreciate any help in developing content and ensuring its accuracy. In > > particular: > > > > - if there are any specific tasks associated with a class or package that > > aren't documented yet, please feel free to update the wiki yourself or > send > > me code fragments with clear descriptions. > > > > - if there is any feedback you have on the organization of the wiki pages > as > > I've set up or if there is some major package I really need to make sure > to > > document, please let me know. > > > > - If there are any issues of accuracy with anything that is on the wiki, > > please let me know. > > > > I've made a point to write and test all sample code that goes up on the > > wiki, so it should work with the latest builds of sugar. But, if things > do > > change with the underlying code or if there are style issues, please do > let > > me know asap. Also, I found some really good conceptual documentation at > > http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines. There are > links > > to more detailed api documentation pages, but these seem to be empty and > in > > need of completion. I think it will be good to link the parts of this > wiki > > that refer to api's to the documentation that I'm helping to set up > above. > > If you have helped write some of the existing documentation, please do > get > > in touch! > > > > Right now, I'm specifically working on documenting the datastore features > of > > sugar and would especially appreciate an opportunity to talk with someone > > with experience with the journal. In addition to email, I should often be > on > > #sugar and #olpc in IRC under the name fanwar. > > Hi Faisal, nice to see you are working on this. > > Any chance we could get a wikibot to update the wiki from the pydocs > in the source? If we can manage to do that I will be happy to make an > additional effort and help completing the api docs in the sugar code. > > Feel free to ask when you have doubts. > > Cheers, > > Tomeu > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
