[sugar] ip4-address buddy property - still needed?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We still have one set of OLPC-specific patches to Salut (the link-local collaboration backend) that has been rejected upstream, which is the one that adds support for the deprecated ip4-address buddy property. This was used during a transitional period to enable simple TCP-based collaboration for activities that didn't use Tubes; Sjoerd is reluctant to keep this patch set, because it's meant to have gone away by now! Is anyone still using this property? If not, can we kill it? It was added in Trial-2, and it was meant to be gone by Trial-3 but was left in just in case, so it really ought to disappear. When it does, we can delete some code from Salut and Presence Service. Places it's exposed in the APIs, which I propose to get rid of: PS D-Bus API: Buddy.GetProperties() returns a dict that contains ip4-address: 10.0.0.1 (or whatever), and Buddy.PropertyChanged signal includes a dict that can contain the same sugar.presence: Buddy has a GLib property ip4-address (aka buddy.props.ip4_address) and can emit it in its property-changed signal The Read activity appears to be the only thing in my jhbuild that uses ip4-address (#4297). It should be ported to either stream tubes (when they're ready in Salut, which should be this or next week) or D-Bus tubes (now). Gabble already supports stream tubes, so stream-tube support can be implemented on a branch and tested against Gabble. Porting from plain TCP to stream tubes should be very straightforward; I hope to produce a proof-of-concept patch for Read later today. Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHIF7HWSc8zVUw7HYRAvp6AJ9G/Xiw27pPPMm0g02vhXzRhzUxqwCfW27Z nh1B/wqe7GD/xf/YaOPVaw8= =42L7 -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Joyride
Could someone *please* explain and document the current process of getting RPMs and XO bundles into the build? Etoys has been broken for weeks now unless I installed the latest bundle manually, just because the XO bundle was not pulled into the build. We're at bundle version Etoys-63 now, the build is still at Etoys-60. A search for joyride comes up virtually empty: http://wiki.laptop.org/go/Special:Search?search=joyride And once the joyride build process is explained, could you outline your intents to killing joy, too? - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Joyride
On 10/25/07, Bert Freudenberg [EMAIL PROTECTED] wrote: Could someone *please* explain and document the current process of getting RPMs and XO bundles into the build? I don't have answers, but I do have clues. https://dev.laptop.org/ticket/4441 links to https://dev.laptop.org/ticket/4251 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] ip4-address buddy property - still needed?
We still have one set of OLPC-specific patches to Salut (the link- local collaboration backend) that has been rejected upstream, which is the one that adds support for the deprecated ip4-address buddy property. Is anyone still using this property? If not, can we kill it? It was added in Trial-2, and it was meant to be gone by Trial-3 but was left in just in case, so it really ought to disappear. Record uses ip4-address, but we've just about completed Record Tubes (and it is working great). ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] ip4-address buddy property - still needed?
It seems, from your discussion like unless someone grumbles today, this should be removed immediately. And it removed within a week, even if someone grumbles... - Jim On Thu, 2007-10-25 at 10:15 +0100, Simon McVittie wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We still have one set of OLPC-specific patches to Salut (the link-local collaboration backend) that has been rejected upstream, which is the one that adds support for the deprecated ip4-address buddy property. This was used during a transitional period to enable simple TCP-based collaboration for activities that didn't use Tubes; Sjoerd is reluctant to keep this patch set, because it's meant to have gone away by now! Is anyone still using this property? If not, can we kill it? It was added in Trial-2, and it was meant to be gone by Trial-3 but was left in just in case, so it really ought to disappear. When it does, we can delete some code from Salut and Presence Service. Places it's exposed in the APIs, which I propose to get rid of: PS D-Bus API: Buddy.GetProperties() returns a dict that contains ip4-address: 10.0.0.1 (or whatever), and Buddy.PropertyChanged signal includes a dict that can contain the same sugar.presence: Buddy has a GLib property ip4-address (aka buddy.props.ip4_address) and can emit it in its property-changed signal The Read activity appears to be the only thing in my jhbuild that uses ip4-address (#4297). It should be ported to either stream tubes (when they're ready in Salut, which should be this or next week) or D-Bus tubes (now). Gabble already supports stream tubes, so stream-tube support can be implemented on a branch and tested against Gabble. Porting from plain TCP to stream tubes should be very straightforward; I hope to produce a proof-of-concept patch for Read later today. Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHIF7HWSc8zVUw7HYRAvp6AJ9G/Xiw27pPPMm0g02vhXzRhzUxqwCfW27Z nh1B/wqe7GD/xf/YaOPVaw8= =42L7 -END PGP SIGNATURE- ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel -- Jim Gettys One Laptop Per Child ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Joyride
On Oct 25, 2007, at 10:32 , Erik Blankinship wrote: On 10/25/07, Bert Freudenberg [EMAIL PROTECTED] wrote: Could someone *please* explain and document the current process of getting RPMs and XO bundles into the build? I don't have answers, but I do have clues. https://dev.laptop.org/ticket/4441 links to https://dev.laptop.org/ticket/4251 Thanks Eric - I've been gathering clues too and I think I actually have an understanding, but still, some official policy is necessary. Also I'm tired of explaining the state of affairs to other developers who do not follow the lists and bug trackers and IRC discussions as closely - I just want a page I can point them to. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] ip4-address buddy property to be replaced by stream tubes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 25 Oct 2007 at 10:37:50 -0400, Benjamin M. Schwartz wrote: Erik Blankinship wrote: Record uses ip4-address, but we've just about completed Record Tubes (and it is working great). Should Activity developers assume that stream tubes will be available in both Gabble and Salut by OLPC 1.0? Yes, I think you should. They work in Gabble at the moment, so you can test collaboration, as long as you make sure you have Internet access. They'll work in Salut (server-less link local collaboration) soon - we have a branch in which they work, but I'm not very happy with the implementation, so it's not in builds yet. If you were previously using ip4-address, using the IPv4 socket type for stream tubes will give you the nearest API match. I patched Read to use stream tubes (patches are attached to #4927) if you want an example. For something like Record it may be best to use a hybrid solution - D-Bus tubes (because of their ability to broadcast) for new photos, and stream tubes (because of their potentially higher efficiency) for newly joined buddies to catch up with the activity state. That's entirely possible, and I can probably help you with the API, although obviously fixing up PS, Gabble and Salut will have to take priority for me. Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHILUaWSc8zVUw7HYRAhTXAKCHuBkdvDOWzhyodPuzXjPypfWSbgCgkPpa O4S+f2hf00k6RrQaJIf6KeI= =uUlt -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] ip4-address buddy property to be replaced by stream tubes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 25 Oct 2007 at 16:24:11 +0100, Simon McVittie wrote: If you were previously using ip4-address, using the IPv4 socket type for stream tubes will give you the nearest API match. I patched Read to use stream tubes (patches are attached to #4927) if you want an example. Oops, I meant #4297. https://dev.laptop.org/ticket/4297 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHILlmWSc8zVUw7HYRAstiAJsHElQOxOBjNJs7paXRsjqJQTK7eQCgvUK3 r2jr1Hn2Y9KyPAHzge2w1ZY= =7Mfb -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Monday Ship Mtg update message
Hi, Kim, I waited until somebody else asks this, but seems that I need to ask^^; How serious is the next deadline? While Etoys did create a new branch after Trial-3 deadline and development is going into the branch, not all our team members are comfortable with the tools enough to follow the joyride hourly builds and test our latest stuff on the actual B4 (and some of our new stuff is not in joyride yet for some reason). And for many developers with B4s, they probably install new build now and then, or stick to the stable builds and try other people's stuff now and then. And as I gather, there are reallly big changes underway. Now, even if the shipment of Trial-3 happens (it has not happened yet, right?) before the next code freeze date, the new code in the branch (not just Etoys' but everything else has similar issues I suppose) will not be tested well by many people, even ourselves, on B4. In this circumstance, how should we proceed? Should we proceed to push the changes to branch? Or is it a bad idea and it should be deferred? Thanks! -- Yoshiki At Mon, 22 Oct 2007 10:43:46 -0400, Kim Quirk wrote: Schedules: This is the last week of changes to the FRS, or Frist Deployment, code base. There are 70+ blocking bugs and over 230 high priority bugs. These should be the highest priority for most people who are helping out in both development and test. After this week, we will hand pick the bug fixes that will go into the build; and start shutting down the code churn. Please look through your bug list, including any other components that might be related to your bug list (sometimes they get put under the wrong component); and figure out what you believe to be the First Deployment show stoppers. Look at bugs that are assigned to the FRS milestone as well as those that have not been assigned or those that are untriaged. This is the code that our first deployment children in Uruguay will experience as well as those who are donating to the G1G1 program -- so we'd like to present the best user experience as possible. Meetings this week (please send me email if you need a call in number and don't have it): Monday 1pm EDT: Test meeting - where are we on the test sprint objectives; highest priority testing for this week Tuesday 12:00 (noon, EDT): Journal/datastore update, saving to the school server Tuesday 12:30 EDT: Tubes, presence, new mesh protocol, jabber servers Wednesday 11:30 EDT: Sugar UI (This might not be the correct time...Christian or Eben will send out time) Wednesday 4:00 pm EDT: Security update (NOTE the change of day) We may need a meeting on connectivity issues (to continue from where we left off with Marvell and Cozybits last week) We may need a meeting dedicated to school server integration We are coming down to the last few weeks. Thanks for everyone's focus and dedication to these difficult details. - Kim ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Monday Ship Mtg update message
Hi Yoshiki, The reason this has seemed fuzzy for a while is because the issues with the relatively new G1G1 program has brought up discussions about dates and how they might change. I think after today's discussion it has been finalized and unchanged from the First Deployment dates that have been in the roadmap for a few months now. https://dev.laptop.org/roadmap November 2, code freeze November 16, drop to quanta For individual activities we will always want people to be able to download from a website pretty much at any time, so further development and features to activities, should continue to be planned and released outside of the olpc schedule. We will stop taking bits for activities that are shipping on the laptop after November 2 (unless you make arrangements with Jim). Hope that helps. Kim On 10/25/07, Yoshiki Ohshima [EMAIL PROTECTED] wrote: Hi, Kim, I waited until somebody else asks this, but seems that I need to ask^^; How serious is the next deadline? While Etoys did create a new branch after Trial-3 deadline and development is going into the branch, not all our team members are comfortable with the tools enough to follow the joyride hourly builds and test our latest stuff on the actual B4 (and some of our new stuff is not in joyride yet for some reason). And for many developers with B4s, they probably install new build now and then, or stick to the stable builds and try other people's stuff now and then. And as I gather, there are reallly big changes underway. Now, even if the shipment of Trial-3 happens (it has not happened yet, right?) before the next code freeze date, the new code in the branch (not just Etoys' but everything else has similar issues I suppose) will not be tested well by many people, even ourselves, on B4. In this circumstance, how should we proceed? Should we proceed to push the changes to branch? Or is it a bad idea and it should be deferred? Thanks! -- Yoshiki At Mon, 22 Oct 2007 10:43:46 -0400, Kim Quirk wrote: Schedules: This is the last week of changes to the FRS, or Frist Deployment, code base. There are 70+ blocking bugs and over 230 high priority bugs. These should be the highest priority for most people who are helping out in both development and test. After this week, we will hand pick the bug fixes that will go into the build; and start shutting down the code churn. Please look through your bug list, including any other components that might be related to your bug list (sometimes they get put under the wrong component); and figure out what you believe to be the First Deployment show stoppers. Look at bugs that are assigned to the FRS milestone as well as those that have not been assigned or those that are untriaged. This is the code that our first deployment children in Uruguay will experience as well as those who are donating to the G1G1 program -- so we'd like to present the best user experience as possible. Meetings this week (please send me email if you need a call in number and don't have it): Monday 1pm EDT: Test meeting - where are we on the test sprint objectives; highest priority testing for this week Tuesday 12:00 (noon, EDT): Journal/datastore update, saving to the school server Tuesday 12:30 EDT: Tubes, presence, new mesh protocol, jabber servers Wednesday 11:30 EDT: Sugar UI (This might not be the correct time...Christian or Eben will send out time) Wednesday 4:00 pm EDT: Security update (NOTE the change of day) We may need a meeting on connectivity issues (to continue from where we left off with Marvell and Cozybits last week) We may need a meeting dedicated to school server integration We are coming down to the last few weeks. Thanks for everyone's focus and dedication to these difficult details. - Kim ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
