Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
On Thu, 2012-10-04 at 21:29 +0100, Peter Robinson wrote: > On Fri, Jul 27, 2012 at 2:51 AM, Jerry Vonau wrote: > > Hi All: > > > > I would like to propose a feature for discussion and inclusion in the > > 0.98 cycle is packaging all control-panel applets as rpms. As this > > discussion does not impact the UI and more of a packaging issue I'm an > > not creating a Features page. The discussion can take place here on the > > mailing-list. > > Feedback and comments welcome, > > I've pushed this and it will appear in the next build, feedback welcome. > > I've left the AboutComputer and AboutMe built in and all the rest are > sub packages. There's a meta-package called sugar-cp-all which pulls > all the Control Panels packages in as well. > > Sorry about the delay. Thank you very much, reviewing now. Jerry ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
On Fri, Jul 27, 2012 at 2:51 AM, Jerry Vonau wrote: > Hi All: > > I would like to propose a feature for discussion and inclusion in the > 0.98 cycle is packaging all control-panel applets as rpms. As this > discussion does not impact the UI and more of a packaging issue I'm an > not creating a Features page. The discussion can take place here on the > mailing-list. > > The reasoning is that it should make it easier for downstream users of > sugar to exclude applets that don't apply to their use case without > having to patch them out. For example OLPC removes via their .spec file, > the keyboard and updater applets from their builds and uses their own > version of an updater supplied as an rpm. > > Dextrose is using this idea to now to partly split up the what is > available to install at rpm generation time[1]. I have found this useful > from a deployment perspective by being able to exclude applets that are > unwanted or need further development from the final image. > > The current code base and workflow would not be changed, except a > revised sugar.spec file would generate more that just the sugar rpm when > run, like how it is done now for sugar-emulator. Deployment level users > of sugar would then need to state which applets to include in their > image at image creation time. This will allow development of applets to > evolve without having to reinstall all of sugar in the field for a > change to an applet. > > Any XO specific user tool like "About my Computer" and "Power" should > not really be part of sugar but should be available to install on demand > like OLPC's sugar-update-control and olpc-switch-desktop that are added > to OLPC's sugar installation. SoaS might benefit from not shipping all > the applets, omitting the ones that apply to XO hardware. > > This change might help development of new features in the control-panel > area that later be incorporated into sugar once proven to work. > > Feedback and comments welcome, I've pushed this and it will appear in the next build, feedback welcome. I've left the AboutComputer and AboutMe built in and all the rest are sub packages. There's a meta-package called sugar-cp-all which pulls all the Control Panels packages in as well. Sorry about the delay. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
On 11 August 2012 08:28, John Gilmore wrote: >> > We have no control over the network environment what so ever and need to >> > work within the confines of what is available. >> >> This is our primary constraint: we cannot install servers or proxies. >> >> Schools in remote areas have latent/slow/expensive Internet links. >> You'd think that a caching proxy is common sense. Unfortunately not :( >> >> Furthermore, the newer wireless networks treat every client as >> potentially hostile and hence prevent them from communicating with >> each other. This also means that no collaboration can take place. > > You *are* sending them XO's or at least XO software loads, yes? > > Fix the XO software with a simple control panel checkbox to make it a > cacheing proxy access point. > > Tell them to configure one of the XOs as a cacheing proxy, stick it in > a corner on permanent power with its ears up, and have the rest > connect to that one, not to the provided "base station". They'll be > one radio hop further away from the Internet (unless you send 'em a > USB Ethernet dongle for that XO), but they'll be able to collaborate > and share, and get much faster access to things that more than one of > them need. > > If there isn't enough storage on those XOs to make a decent cache, > send 'em a 16GB USB stick or a similar SD card too. The key is simplicity for the end user. Nothing can require technical expertise. We have a solution for manual updates [1]. This is a fallback if the automated updates mechanism is not appropriate. The automated updates mechanism (which uses yum) is great for schools as no expertise is required to set anything up. If you don't make it automatic (or at very least, extremely easy), it won't happen. But back on topic, it would benefit everyone if Sugar packaging was more modular, to give deployments greater control over that they distribute and to keep updates sizes to a minimum. We're happy to help make that happen - we aren't just criticising from the sidelines. Sridhar [1] https://dev.laptop.org.au/issues/873 Sridhar Dhanapalan Engineering Manager One Laptop per Child Australia ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
On Fri, 2012-08-10 at 15:28 -0700, John Gilmore wrote: > > > We have no control over the network environment what so ever and need to > > > work within the confines of what is available. > > > > This is our primary constraint: we cannot install servers or proxies. > > > > Schools in remote areas have latent/slow/expensive Internet links. > > You'd think that a caching proxy is common sense. Unfortunately not :( > > > > Furthermore, the newer wireless networks treat every client as > > potentially hostile and hence prevent them from communicating with > > each other. This also means that no collaboration can take place. > > You *are* sending them XO's or at least XO software loads, yes? > > Fix the XO software with a simple control panel checkbox to make it a > cacheing proxy access point. > I can see a caching proxy, but without a second network interface I see no point in creating a access point. The share this modem connection[1] that is available in Dextrose3 is a great step in the right direction, but needs to be extended to include any second network interface that might be added to an XO. That would open up lots of different options when out in the field at deployment time. You also must take into account the internet policies that are in place at the schools, some require individuals to authenticate at their school's proxy with their userid/password before internet access is granted. We need to be flexible, there is no one size fits all solution. > Tell them to configure one of the XOs as a cacheing proxy, stick it in > a corner on permanent power with its ears up, and have the rest > connect to that one, not to the provided "base station". That fits into our bigger plan for a XS like appliance that can be added to the base fedora/sugar software foundation of an XO with a control panel applet to configure services offered. I'm looking at the using avahi to advertise services offered for example a jabber server, a yum repo, a activities repo, backup space, by the appliance to be discovered by the client XOs. > They'll be > one radio hop further away from the Internet (unless you send 'em a > USB Ethernet dongle for that XO), but they'll be able to collaborate > and share, and get much faster access to things that more than one of > them need. > I agree that a proxy could be setup but the client side on the XO would still need to be configured to use it. We are dealing with non-technical people in the field, this would need to "just work" out of the box with very little work by the people deploying the XOs. For a initial working model I'm thinking that we could create a new applet to search for services of interest that are available via avahi and have check-boxes to enable connections to services that the XO could use. Say for example discover a jabber server, tick the box for that service and the gconf key for the collaboration server becomes populated. The proxy service could be advertised and enabled in the same way. Being able to customize solutions without having a XS's rigid network layout becomes a whole pile easier and opens up numerous possibilities in the field. > If there isn't enough storage on those XOs to make a decent cache, > send 'em a 16GB USB stick or a similar SD card too. > I think that would be a good option with the above planned appliance as we need a place to store/serve data from. > John Jerry 1. http://wiki.sugarlabs.org/go/Features/3G_Support/Share ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
> > We have no control over the network environment what so ever and need to > > work within the confines of what is available. > > This is our primary constraint: we cannot install servers or proxies. > > Schools in remote areas have latent/slow/expensive Internet links. > You'd think that a caching proxy is common sense. Unfortunately not :( > > Furthermore, the newer wireless networks treat every client as > potentially hostile and hence prevent them from communicating with > each other. This also means that no collaboration can take place. You *are* sending them XO's or at least XO software loads, yes? Fix the XO software with a simple control panel checkbox to make it a cacheing proxy access point. Tell them to configure one of the XOs as a cacheing proxy, stick it in a corner on permanent power with its ears up, and have the rest connect to that one, not to the provided "base station". They'll be one radio hop further away from the Internet (unless you send 'em a USB Ethernet dongle for that XO), but they'll be able to collaborate and share, and get much faster access to things that more than one of them need. If there isn't enough storage on those XOs to make a decent cache, send 'em a 16GB USB stick or a similar SD card too. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
On 2 August 2012 21:06, Jerry Vonau wrote: > On Thu, 2012-08-02 at 09:53 +0100, Peter Robinson wrote: >> Do you have any form of proxy? A local transparent proxy would mean >> 400 XOs still only download 800Kb over the link. There's lots of ways >> to skin a cat. >> > > We have no control over the network environment what so ever and need to > work within the confines of what is available. This is our primary constraint: we cannot install servers or proxies. Schools in remote areas have latent/slow/expensive Internet links. You'd think that a caching proxy is common sense. Unfortunately not :( Furthermore, the newer wireless networks treat every client as potentially hostile and hence prevent them from communicating with each other. This also means that no collaboration can take place. Sridhar Sridhar Dhanapalan Engineering Manager One Laptop per Child Australia M: +61 425 239 701 E: srid...@laptop.org.au A: G.P.O. Box 731 Sydney, NSW 2001 W: www.laptop.org.au ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
On Thu, 2012-08-02 at 09:53 +0100, Peter Robinson wrote: > On Thu, Aug 2, 2012 at 1:59 AM, Sridhar Dhanapalan > wrote: > > On 30 July 2012 23:26, Jerry Vonau wrote: > >> The idea works well for users of Dextrose where OLPC-AU as a deployment > >> could omit features that are still under development and not show the > >> icon the control-panel at all. I'm not asking for anything to be > >> removed, just packaged and made available separately. > >> > >> Once the spec file is altered OOB users would state which of the applets > >> to install or substitute their own. The one rub would be having to alter > >> the sugar-desktop group definition available from fedora's repos. > >> > >> Just trying to ease the burden on some of us deployments. > > > > This feature would make maintenance of code and updates in the field > > much easier for us. > > As I've said I'm happy to make improvements but I also want to make > sure that one change that helps one group of people doesn't hinder > others. Please don't see this as rejection, I'm just assessing all > possibilities and gathering other opinions. > > > As a deployment, we would like the choice of which CP applets to > > include, or even make substitutions if need be. We don't want to be > > making unnecessary patches or building our own Sugar RPM just for > > this. That would in effect be a fork of Sugar and become a maintenance > > burden for us. > > Yes, I agree, but in some cases, such as the network panel, it might > be that it's dependant on other code elsewhere so it might not make > sense. > We have a toggle for the wifi at a known location, a function to write a gconf key that sugar knows about, and the ability to delete a known sugar file. That is hardly fully integrated, while improvements that could go upstream there is no quick means of testing without an rpm to test with. This will open up an avenue for quicker testing, you can be assured that the core sugar code base has not been altered while comparing the new applet code, and is a smaller download to boot. In my opinion should "about my computer" gain a dependency on bitfrost's API this would be the logical place to add the 'requires', sugar doesn't have bitfrost as a dependency at the moment while sugar-update-control does. > > We use yum to provide automatic updates to our XOs in the field, and > > we must be mindful that large RPMs can have an impact on the school's > > Internet connection. If 400 XOs need to download a ~800KB Sugar RPM, > > that's 320MB being downloaded, potentially at the same time. > > Do you have any form of proxy? A local transparent proxy would mean > 400 XOs still only download 800Kb over the link. There's lots of ways > to skin a cat. > We have no control over the network environment what so ever and need to work within the confines of what is available. > As for rpm updates I would be interested to hear how you're > distributing and pushing them out, I've had a number of queries over > the years about distribution of updates so it might be worthwhile to > document some things centrally. We have two ways of pushing out rpm updates. First is the offline method using our One Education USB[1] tookit with some Customization Stick[2] alterations[3]. Second is DX3's[4] sugar-client[5] to check for yum updates in repos that we maintain. Jerry 1.https://dev.laptop.org.au/projects/xo-au-usb/wiki/Wiki 2.http://wiki.laptop.org/go/Customization_stick_development 3.https://dev.laptop.org.au/projects/xo-au-usb/repository/revisions/master/show/dracut 4.http://wiki.sugarlabs.org/go/Dextrose/3 5.http://wiki.sugarlabs.org/go/Sugar_Server_Kit/sugar-client ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
On Thu, Aug 2, 2012 at 5:04 AM, James Cameron wrote: > For deployments that eschew servers, a caching proxy won't help. But > on the other hand, sharing the updates across a bunch of XOs might be > possible using a torrent-like implementation. Facebook uses torrents to distribute their rpm and web site updates, they have a custom algorithm that favours rack, then row, then DC. It allowed them to cut their time to push out updates to all their servers by an order of magnitude to their previous means. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
On Thu, Aug 2, 2012 at 1:59 AM, Sridhar Dhanapalan wrote: > On 30 July 2012 23:26, Jerry Vonau wrote: >> The idea works well for users of Dextrose where OLPC-AU as a deployment >> could omit features that are still under development and not show the >> icon the control-panel at all. I'm not asking for anything to be >> removed, just packaged and made available separately. >> >> Once the spec file is altered OOB users would state which of the applets >> to install or substitute their own. The one rub would be having to alter >> the sugar-desktop group definition available from fedora's repos. >> >> Just trying to ease the burden on some of us deployments. > > This feature would make maintenance of code and updates in the field > much easier for us. As I've said I'm happy to make improvements but I also want to make sure that one change that helps one group of people doesn't hinder others. Please don't see this as rejection, I'm just assessing all possibilities and gathering other opinions. > As a deployment, we would like the choice of which CP applets to > include, or even make substitutions if need be. We don't want to be > making unnecessary patches or building our own Sugar RPM just for > this. That would in effect be a fork of Sugar and become a maintenance > burden for us. Yes, I agree, but in some cases, such as the network panel, it might be that it's dependant on other code elsewhere so it might not make sense. > We use yum to provide automatic updates to our XOs in the field, and > we must be mindful that large RPMs can have an impact on the school's > Internet connection. If 400 XOs need to download a ~800KB Sugar RPM, > that's 320MB being downloaded, potentially at the same time. Do you have any form of proxy? A local transparent proxy would mean 400 XOs still only download 800Kb over the link. There's lots of ways to skin a cat. As for rpm updates I would be interested to hear how you're distributing and pushing them out, I've had a number of queries over the years about distribution of updates so it might be worthwhile to document some things centrally. Regards, Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
For deployments that eschew servers, a caching proxy won't help. But on the other hand, sharing the updates across a bunch of XOs might be possible using a torrent-like implementation. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
> We use yum to provide automatic updates to our XOs in the field, and > we must be mindful that large RPMs can have an impact on the school's > Internet connection. If 400 XOs need to download a ~800KB Sugar RPM, > that's 320MB being downloaded, potentially at the same time. Isn't there a cacheing yum proxy? Yes, it turns out: http://terrarum.net/administration/caching-rpms-with-pkg-cacher.html [Beware the install advice in that page. It tells you to set gpgcheck=0 to install their packages -- rather than telling you where to get a public key -- and it neglects to tell you to restore gpgcheck=1 after you install pkg-cacher.] Supposedly apt-cache can do it as well, though I don't see a step-by-step guide: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482949 Once one of your local machines is running the proxy, then you point each of the XOs to the proxy as well as to the standard RPM repos. I think yum is smart enough to download it from the first repo that offers it, which means that if your cache is responding, it'll download packages from there. (Warning: I haven't done this myself.) John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
On 30 July 2012 23:26, Jerry Vonau wrote: > The idea works well for users of Dextrose where OLPC-AU as a deployment > could omit features that are still under development and not show the > icon the control-panel at all. I'm not asking for anything to be > removed, just packaged and made available separately. > > Once the spec file is altered OOB users would state which of the applets > to install or substitute their own. The one rub would be having to alter > the sugar-desktop group definition available from fedora's repos. > > Just trying to ease the burden on some of us deployments. This feature would make maintenance of code and updates in the field much easier for us. As a deployment, we would like the choice of which CP applets to include, or even make substitutions if need be. We don't want to be making unnecessary patches or building our own Sugar RPM just for this. That would in effect be a fork of Sugar and become a maintenance burden for us. We use yum to provide automatic updates to our XOs in the field, and we must be mindful that large RPMs can have an impact on the school's Internet connection. If 400 XOs need to download a ~800KB Sugar RPM, that's 320MB being downloaded, potentially at the same time. Sridhar Sridhar Dhanapalan Engineering Manager One Laptop per Child Australia ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
On Mon, 2012-07-30 at 10:14 +0100, Peter Robinson wrote: > On Mon, Jul 30, 2012 at 3:43 AM, Jerry Vonau wrote: > > On Mon, 2012-07-30 at 00:20 +0100, Peter Robinson wrote: > >> On Fri, Jul 27, 2012 at 4:42 PM, Daniel Drake wrote: > >> > On Thu, Jul 26, 2012 at 7:51 PM, Jerry Vonau wrote: > >> >> I would like to propose a feature for discussion and inclusion in the > >> >> 0.98 cycle is packaging all control-panel applets as rpms. As this > >> >> discussion does not impact the UI and more of a packaging issue I'm an > >> >> not creating a Features page. The discussion can take place here on the > >> >> mailing-list. > >> > > >> > This sounds like a good idea. Indeed, its not a sugar feature request, > >> > its more a packaging detail. > >> > > >> > Peter, what do you think about splitting the cpsection extensions (in > >> > /usr/share/sugar) into individual subpackages, to be selected by the > >> > Sugar Desktop group but not as direct dependencies of the Sugar > >> > packages? For F18+ > >> > >> I've had a bit more of a look at this. Any thoughts on what should be > >> split out and what shouldn't. The language/keyboard obviously should > >> be split out. Are there ones we should most definitely have (hence not > >> split out)? > > > > I'm aiming to have this done at the sugar packaging level, before OLPC > > has releases their version. Of the 10 applets lets look at the > > breakdown: > > > > Language - agreed with > > > > Keyboard - agreed with > > > > Updater - patched out to use OLPC's version for microformat > > The above 3 I agree with splitting out. > Good some agreement. > > Power - XO specific code > > > > About my Computer - XO specific code > > It's not XO specific code except the serial number in Identity and > there's no reason that can't pull the details for the other machine > details if it's not an XO. The build is taken from the > /boot/olpc_build file and you can put what ever you like in there. It > also includes the license details which really shouldn't be removed. > So disabling powerd, Firmware, Build, Serial Number, and Lease are not XO specific? > > Modem Configuration - distro specific. > > It's not, it should be using the configuration from ModemManager which > is used by all the major distros for 3G stuff. > Yea they're inter-dependant, but what will differ are the plugins used by the distro for NetworkManager. > > Date & time - is distro specific, doesn't work work right doesn't change > > system hence gnome is wrong. > > Then it's likely a bug that should be fixed rather than just plain removed. > Sugar doesn't ship gnome, and a bug has been filed. In the meantime while in development you don't have to reinstall all of sugar to test changes to an applet. Work the bugs out and pass upstream for inclusion in sugar proper. > > Network - distro specific - to be able to add features without touching > > base sugar. > > Again, uses NetworkManager like the rest of the Network code in Sugar. > All major distros use NetworkManager and there's a lot of other code > that needs to be changed all over the shell and toolkit to be able to > remove NetworkManager. In 0.94+ (maybe 0.96 and we back ported it for > 0.94 in Fedora) it uses NM 0.9 and shares configuration with gnome. > No need to remove, just change packaging in the spec file. The applet has the Server box, discard network history and radio. Getting the proxy settings interface upstream is still on the Features list but working here. :) > Shouldn't the features be going upstream rather than just plain > forking the code? Also you'd need to patch other components of sugar > to change the network code. > Not really, for example you could add functions that don't impact sugar directly like setting of NTP servers to use without having to touch sugar's inner workings. Call up NM applet with a button to test advanced options where Neighbourhood View doesn't offer them like configuring a wired usb interface, or hidden SSIDs. The features will go upstream when excepted upstream. In the meantime the deployment doesn't have to re-roll sugar when an update comes out if there were no changes to the applets. Just like software updater and switch-desktop are standalone at the moment. > > Frame - To be able to add features without touching base sugar. > > > > About Me - only one left. > > > > I'd say all of the applets. You now pick and choose the ones to include > > at image creation time, SoaS included. The same rpm that is offered by > > fedora should be the same as the one offered by OLPC. > > I agree but in the case of SoaS there's likely only one I would want to > remove. > Just wondering which one? > > This should ease development of new features in this area with > > development not being tied to the release schedule of base sugar. One > > could develop an alternate to what is offered, prove it works then pass > > it upstream for inclusion in the next cycle, on a much smaller code > > base. > > In some
Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
On Mon, Jul 30, 2012 at 3:43 AM, Jerry Vonau wrote: > On Mon, 2012-07-30 at 00:20 +0100, Peter Robinson wrote: >> On Fri, Jul 27, 2012 at 4:42 PM, Daniel Drake wrote: >> > On Thu, Jul 26, 2012 at 7:51 PM, Jerry Vonau wrote: >> >> I would like to propose a feature for discussion and inclusion in the >> >> 0.98 cycle is packaging all control-panel applets as rpms. As this >> >> discussion does not impact the UI and more of a packaging issue I'm an >> >> not creating a Features page. The discussion can take place here on the >> >> mailing-list. >> > >> > This sounds like a good idea. Indeed, its not a sugar feature request, >> > its more a packaging detail. >> > >> > Peter, what do you think about splitting the cpsection extensions (in >> > /usr/share/sugar) into individual subpackages, to be selected by the >> > Sugar Desktop group but not as direct dependencies of the Sugar >> > packages? For F18+ >> >> I've had a bit more of a look at this. Any thoughts on what should be >> split out and what shouldn't. The language/keyboard obviously should >> be split out. Are there ones we should most definitely have (hence not >> split out)? > > I'm aiming to have this done at the sugar packaging level, before OLPC > has releases their version. Of the 10 applets lets look at the > breakdown: > > Language - agreed with > > Keyboard - agreed with > > Updater - patched out to use OLPC's version for microformat The above 3 I agree with splitting out. > Power - XO specific code > > About my Computer - XO specific code It's not XO specific code except the serial number in Identity and there's no reason that can't pull the details for the other machine details if it's not an XO. The build is taken from the /boot/olpc_build file and you can put what ever you like in there. It also includes the license details which really shouldn't be removed. > Modem Configuration - distro specific. It's not, it should be using the configuration from ModemManager which is used by all the major distros for 3G stuff. > Date & time - is distro specific, doesn't work work right doesn't change > system hence gnome is wrong. Then it's likely a bug that should be fixed rather than just plain removed. > Network - distro specific - to be able to add features without touching > base sugar. Again, uses NetworkManager like the rest of the Network code in Sugar. All major distros use NetworkManager and there's a lot of other code that needs to be changed all over the shell and toolkit to be able to remove NetworkManager. In 0.94+ (maybe 0.96 and we back ported it for 0.94 in Fedora) it uses NM 0.9 and shares configuration with gnome. Shouldn't the features be going upstream rather than just plain forking the code? Also you'd need to patch other components of sugar to change the network code. > Frame - To be able to add features without touching base sugar. > > About Me - only one left. > > I'd say all of the applets. You now pick and choose the ones to include > at image creation time, SoaS included. The same rpm that is offered by > fedora should be the same as the one offered by OLPC. I agree but in the case of SoaS there's likely only one I would want to remove. > This should ease development of new features in this area with > development not being tied to the release schedule of base sugar. One > could develop an alternate to what is offered, prove it works then pass > it upstream for inclusion in the next cycle, on a much smaller code > base. In some cases I agree, as documented above developing others, like Network, require changes in other areas of the core sugar code so IMO don't make much sense. I can still be convinced though, and of course like everything if we make one decision today doesn't mean it can't change down the road. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
On Mon, 2012-07-30 at 00:20 +0100, Peter Robinson wrote: > On Fri, Jul 27, 2012 at 4:42 PM, Daniel Drake wrote: > > On Thu, Jul 26, 2012 at 7:51 PM, Jerry Vonau wrote: > >> I would like to propose a feature for discussion and inclusion in the > >> 0.98 cycle is packaging all control-panel applets as rpms. As this > >> discussion does not impact the UI and more of a packaging issue I'm an > >> not creating a Features page. The discussion can take place here on the > >> mailing-list. > > > > This sounds like a good idea. Indeed, its not a sugar feature request, > > its more a packaging detail. > > > > Peter, what do you think about splitting the cpsection extensions (in > > /usr/share/sugar) into individual subpackages, to be selected by the > > Sugar Desktop group but not as direct dependencies of the Sugar > > packages? For F18+ > > I've had a bit more of a look at this. Any thoughts on what should be > split out and what shouldn't. The language/keyboard obviously should > be split out. Are there ones we should most definitely have (hence not > split out)? I'm aiming to have this done at the sugar packaging level, before OLPC has releases their version. Of the 10 applets lets look at the breakdown: Language - agreed with Keyboard - agreed with Updater - patched out to use OLPC's version for microformat Power - XO specific code About my Computer - XO specific code Modem Configuration - distro specific. Date & time - is distro specific, doesn't work work right doesn't change system hence gnome is wrong. Network - distro specific - to be able to add features without touching base sugar. Frame - To be able to add features without touching base sugar. About Me - only one left. I'd say all of the applets. You now pick and choose the ones to include at image creation time, SoaS included. The same rpm that is offered by fedora should be the same as the one offered by OLPC. This should ease development of new features in this area with development not being tied to the release schedule of base sugar. One could develop an alternate to what is offered, prove it works then pass it upstream for inclusion in the next cycle, on a much smaller code base. Jerry ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
On Fri, Jul 27, 2012 at 4:42 PM, Daniel Drake wrote: > On Thu, Jul 26, 2012 at 7:51 PM, Jerry Vonau wrote: >> I would like to propose a feature for discussion and inclusion in the >> 0.98 cycle is packaging all control-panel applets as rpms. As this >> discussion does not impact the UI and more of a packaging issue I'm an >> not creating a Features page. The discussion can take place here on the >> mailing-list. > > This sounds like a good idea. Indeed, its not a sugar feature request, > its more a packaging detail. > > Peter, what do you think about splitting the cpsection extensions (in > /usr/share/sugar) into individual subpackages, to be selected by the > Sugar Desktop group but not as direct dependencies of the Sugar > packages? For F18+ I've had a bit more of a look at this. Any thoughts on what should be split out and what shouldn't. The language/keyboard obviously should be split out. Are there ones we should most definitely have (hence not split out)? Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
On Fri, Jul 27, 2012 at 4:42 PM, Daniel Drake wrote: > On Thu, Jul 26, 2012 at 7:51 PM, Jerry Vonau wrote: >> I would like to propose a feature for discussion and inclusion in the >> 0.98 cycle is packaging all control-panel applets as rpms. As this >> discussion does not impact the UI and more of a packaging issue I'm an >> not creating a Features page. The discussion can take place here on the >> mailing-list. > > This sounds like a good idea. Indeed, its not a sugar feature request, > its more a packaging detail. > > Peter, what do you think about splitting the cpsection extensions (in > /usr/share/sugar) into individual subpackages, to be selected by the > Sugar Desktop group but not as direct dependencies of the Sugar > packages? For F18+ Yes, I agree, I read this earlier and tagged it for follow up. It certainly makes sense and allows us to package things up properly and if it makes it easier for deployments I'm all for it. It would also make it easier to swap out certain components too. Regards, Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
On Thu, Jul 26, 2012 at 7:51 PM, Jerry Vonau wrote: > I would like to propose a feature for discussion and inclusion in the > 0.98 cycle is packaging all control-panel applets as rpms. As this > discussion does not impact the UI and more of a packaging issue I'm an > not creating a Features page. The discussion can take place here on the > mailing-list. This sounds like a good idea. Indeed, its not a sugar feature request, its more a packaging detail. Peter, what do you think about splitting the cpsection extensions (in /usr/share/sugar) into individual subpackages, to be selected by the Sugar Desktop group but not as direct dependencies of the Sugar packages? For F18+ Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
Hi All: I would like to propose a feature for discussion and inclusion in the 0.98 cycle is packaging all control-panel applets as rpms. As this discussion does not impact the UI and more of a packaging issue I'm an not creating a Features page. The discussion can take place here on the mailing-list. The reasoning is that it should make it easier for downstream users of sugar to exclude applets that don't apply to their use case without having to patch them out. For example OLPC removes via their .spec file, the keyboard and updater applets from their builds and uses their own version of an updater supplied as an rpm. Dextrose is using this idea to now to partly split up the what is available to install at rpm generation time[1]. I have found this useful from a deployment perspective by being able to exclude applets that are unwanted or need further development from the final image. The current code base and workflow would not be changed, except a revised sugar.spec file would generate more that just the sugar rpm when run, like how it is done now for sugar-emulator. Deployment level users of sugar would then need to state which applets to include in their image at image creation time. This will allow development of applets to evolve without having to reinstall all of sugar in the field for a change to an applet. Any XO specific user tool like "About my Computer" and "Power" should not really be part of sugar but should be available to install on demand like OLPC's sugar-update-control and olpc-switch-desktop that are added to OLPC's sugar installation. SoaS might benefit from not shipping all the applets, omitting the ones that apply to XO hardware. This change might help development of new features in the control-panel area that later be incorporated into sugar once proven to work. Feedback and comments welcome, Jerry 1.http://git.sugarlabs.org/dextrose/mainline/blobs/bleeding-edge/rpms/sugar/sugar.spec ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
