<div dir="ltr">On 12 May 2014 21:07, Gonzalo Odiard <span dir="ltr"><<a href="mailto:godiard@sugarlabs.org" target="_blank">godiard@sugarlabs.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">First, thanks for doing this work. <div class="gmail_extra"><div class="gmail_quote"> <div class=""> <div><br></div></div></div></div></div></blockquote><div><br></div><div>Thanks for helping out.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"> <div><div><div> <div> <div>I would like to take a step back and understand a bit better where we want to go with this. Some random thoughts and questions.<br> <br>* To really understand how much work is left I think we need some good testing, especially on the hardware related bits. I expect there will be lots of small things to fix, but it would be good to understand as early as possible if there are roadblocks. I'm a bad tester and I've never used the XO much, so I'm often not sure what is a regression and what is not... thus helping with this would be particularly appreciated.<br> </div></div></div></div></div></div></blockquote><div><br></div></div><div>This is a issue. If we have a Sugar with similar functionalities (settings and activities installed) we can request help from deployments and volunteers. </div> </div></div></div></blockquote><div><br></div><div class="">Are you thinking to deployment specific settings and activities here? Or some kind of subset/reference that is good enough for all the interested deployments?<br> </div><div class=""><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>* Should we contribute the olpc-os-builder changes back to OLPC or fork it? I don't know if OLPC will do any active development on the linux side of things, if not maybe better to turn this into a sugarlabs thing.<br> </div></div></div></div></blockquote><div><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"> <div>Probably James would know better respect of this issue. The changes we did for AU are in a fork [1], but are not low level stuff,</div><div>just configurations.</div><div class=""> <div></div></div></div></div></div></blockquote><div><br></div><div>Yes. I don't really have a strong feeling one way or another. I can send patches for the generic parts if they are wanted.<br><br>I think we also need a place where to put reference configurations. I initially had put them in olpc-os-builder, numbered as 14.0.0 but that feels wrong... since no official olpc releases are planned. I suppose I could edit the examples/f18-[model].ini ones instead, but I would need access to whatever repository we use to change those without needing review every time.<br> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div><div><div> </div>* Are interested deployments using olpc-update? If I'm not mistake AU is not.<br></div></div></div></blockquote><div><br></div></div><div>We are not using it. I am pretty sure Nicaragua use it.</div><div class=""> <div></div></div></div></div></div></blockquote><div><br></div><div>Is AU using yum?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div><div></div>* Do we care about maintaining the GNOME "dual boot"? I'm afraid we do, but I want to make sure.<br></div></div></blockquote><div><br></div></div><div>Yes. Is a important feature for the deployments. In the end deployments don't ask for "Gnome", but for a standard desktop,</div> <div>for some cases. If Gnome don't work without acceleration in F20, XFCE, mate or similar can work.</div></div></div></div></blockquote><div><br></div><div>I've seen screenshots of GNOME fallback in F20, so I'm hopeful it's still there. But yeah, in the worst case there are alternatives.<br> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""> <div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div></div>* As I mentioned in some other thread I'm interested in setting up automated builds from sugar master. I have some vague plan of what it would look like and wrote bits of it. The basic idea is that you would push changes to github and get images automatically built. I think this is good for upstream testing but the same infrastructure could be used by deployments. Are people interested in using this?<br> </div> </blockquote></div></div><br>I am not sure if do a complete build for every sugar commit have sense, maybe yes do weekly builds, or automatic rpms.</div></div></blockquote><div><br></div><div>Yeah, weekly images and one rpm per commit was pretty much what I had in mind. (With yum based updates doing frequent builds is less important by the way). Well, it's probably good to have one image per commit to the build configurations repository, but that's different.<br> </div></div></div></div>