Software discussion 2009-01-09
Short version
This meeting was about plans for how OLPC software will work given the recent staffing changes.
cjb: we've outlined a plan about how you might be able to keep developing software even after you lay off almost all of your engineers (I consider being part of generating this plan to be the crowning achievement of my career so far, frankly, because the idea of continuining development right now is so manifestly ridiculous.) and, we can spend a while to think about that plan. we don't have to agree right now.
The situation
See http://blog.laptop.org/2009/01/07/refocusing-on-our-mission/
Some questions: does OLPC ever want to make another software release? Why? Is that compatible with laying off basically the entire engineering team? And so on.
Although OLPC can no longer fund software development the way we were, our "wish list" for what software might be on our machines hasn't materially changed. We're just no longer in a position to make those wishes come true ourselves (or less so, in that volunteer contributions were always important). By "wish list" I meant to indicate that all the things we were saying were important we still think are important. I guess I'm reacting to the "OLPC dumps Sugar" headlines. But we need to figure out how to make it possible/easy for people who ARE able to move OLPC software development forward to do so.
How this affects our previously planned releases
The nutshell: we finish 8.2.1 as planned, and merge into F11 (or F12, if not finished by F11-time) for future software releases; at that point, Software Is Fedora's Problem and OLPC is along for the ride.
Yes 8.2.1 release
8.2.1 is happening, and development will consist of incorporating features into the current software that we have (no fedora rebase yet). Roles remain the same; Ed will continue being the release manager, and Mel will continue being the test manager (as a volunteer).
No 9.1.0 release
OLPC will not be guaranteeing a 9.1.0 release early this year.
Beyond 8.2.1
Beyond that, we (meaning OLPC in capital letters) has no ability/right to state - on its own - what a future release would look like or how it will happen.
It is very important that OLPC's remaining staff take responsibility for providing assistance to any interested parties wishing to participate in the evolution of XO software. The "assistance" we provide may be "go look at F11".
Grand Unified Distro (GUD) Theory
Proposal: Move rapidly towards shipping straight Fedora, putting development efforts towards making Fedora into what we want to ship (working on our own patches to F11/F12/etc as appropriate - upstreamed, not forks).
The nice thing about making our release be F11 is that Fedora actually has release managers, bug triage teams, and support resources, and string freezes, and that kind of coordination. It naturally brings along more workload reductions with it.. we can't fork packages, etc
We're not talking about running GNOME and everything in Fedora, like we did for the Fedora-on-XO-on-SD thing. I'm talking about the system looking exactly the same as e.g. 767 (or 8.2.1) but being obtainable from a straight Fedora release. Let's call this Fedora-8.2.1, a recreation of the build from upstream fedora.
So what we previously called the "9.1 release" is probably mostly about reconciling a new process to onboard community engineers and take advantage of Fedora's preexisting release engineering process.
Current progress
edmcnierney has been talking to gregdek about helping stimulate the small-but-growing Fedora-on-small-systems community.
Here at fudcon, we are looking at every "fork" we have in koji against stock F10 and working out how to get rid of those forks. once the forks go away, we are at Fedora-8.2.1.
ericg already has a fedora 10 spin which fits in the NAND, runs fine, and is just based on a list of packages yum-installed into a minimal chroot. it has bugs but it works. there were only two forks, initramfs and kernel. bare install, xfce base, minimal stuff, is 600 mb uncompressed, and much less compressed, maybe 400; people are very interested in testing this and erikg will push updates to repo.
On scheduling
Try for F11 (May). We'll probably not make it, but we can clean up for F12 (Dec) as anything we prepare for F11 will automatically be in F12.
There may be some regressions of features in 767 that might not make it in to the first rebase. We will have put a huge feature in, i.e. mainteinability, at the cost of a few regressions.
Counterproposals
but maintainability is ... well it's ok if the laptops in the field skip a fedora release and upgrade from a F9-based XOOS to a F11 based one... in fact, I'll say something radical — both on laptop and server, we want to work with gregdek to switch to the CentOS stable branch. with the next RHEL/Centos, it'll be smallish, and we can pick and choose a few things to backport.
Using fedora build tools
...will be a challenge.
- use fedora tools to make a rawhide spin that boots from SD
- get Pilgrim accepted by fedora (or we'll have to abandon it)
- use livecd-tools? (from Fedora)
- the prob is that livecd-tools doesn't provide all that we need
- mainly initrd/security stuff needs to be dealt with
- its something we have to work with fedora on
- well, at least we're at a conference full of people who know something about the problem
- jeremy is enumerating the things we need to do to get fedora build tools working
Questions and Concerns
- fedora really doesn't seem targeted for small, "embedded" systems
- Where is localization of UI strings going to take place?
- At Sugar Labs. Pootle will migrate there.
- a large proportion of our forks have originated simply because Fedora goals and audiences are significantly different from our own. Will we be able to eliminate them?
- counter: a large number have recently disappeared because the Fedora folks are entirely willing to split out packages when that happens.
- antitheft: we could tell countries that we're sending out all further laptops with security disabled, and we say "hey, here's some code you might like if you want to deploy a security server."
- oh, no-one pointed out the largest flaw in my plan of renaming 9.1 to Fedora 11, which is that we're in the middle of moving to F10 and F11 feature freeze is in two months. my plan requires that we now move to F11, pretty much immediately.
What happens to deployments?
What OLPC will tell them
Cjb: Mainly what I'm interested in right now is edmcnierney saying that it's okay with him if we tell our deployments "You should run 767, and we might have something better in May, and if not we might have something better in December."
Edmcnierney: What I'm going to be saying is that 8.2.1 is what they should use/upgrade to when we release it, and that we will update the factory to start using that release, and going forward they should look to the next release to be a Sugar-on-Fedora spin for the XO. And that's a combination of software released by Fedora and Sugar Labs, not OLPC.
The future of collecting user feedback
regarding how/where feature requests for 9.1 and from deployments go and get triaged, part of OLPC's job going forward is to collect that input and communicate it to the Fedora / Sugar Labs communities as appropriate. Our value is being a good source for that field input.
Is the eventual goal of direct communication between deployments and sugarlabs/fedora? I think direct communication is fine - no reason to get in the way - but some deployments will find it easier/preferable to talk to OLPC, so we should be responsible for passing on that information. This is an important part of Reuben's job.
The game plan
Rid ourselves of the OLPC monopoly on build signing/dev keys
An obvious thing to do is to help deployments be able to take care of themselves -- have them in charge of dev keys, build signing, build creation, and so on. at this point the deployments can do whatever they want. Mitch Bradley is doing the firmware work to support this.
Push infrastructure out to the community
We'll start pushing infrastructure out to the community. This includes Pootle going to SL, git going to SL, packages going upstream to Fedora instead of in our dropboxes...
Start thinking about planning a release
When I say "planning a release", I mean "getting everything into Fedora in time for their release."
Best proposal of the day
"...we can base [the XO's build] on Debian Potato."
Log
cjb> Would it be useful for me to give some recent thoughts on this stuff? Jan 09 15:07:25 * _bjordan (n=bjordan@dhcp-49-80.media.mit.edu) has joined #olpc-meeting edmcnierney> I really meant, "Please don't expect me to run it, because I'm going to be interrupted by people who really do need my help". mchua> go go gadget cjb! edmcnierney> cjb: +1 dsd_> well, before that cjb> go ahead, dsd_ dsd_> what is the situation? dsd_> are there plans for how software will work given these changes dsd_> or is that what we're discussing today? cjb> I haven't heard any plans, if they exist Jan 09 15:08:35 * mchua thought that was the game plan for today. cjb> an obvious thing to do is to help deployments be able to take care of themselves -- have them in charge of dev keys, build signing, build creation, and so on edmcnierney> dsd_: Here's the way I look at it. cjb> but after we've done that, we'll get back to the same question, which is.. does OLPC ever want to make another software release? Why? Is that compatible with laying off basically the entire engineering team? And so on. edmcnierney> Although OLPC can no longer fund software development the way we were, our "wish list" for what software might be on our machines hasn't materially changed. edmcnierney> We're just no longer in a position to make those wishes come true ourselves (or less so, in that volunteer contributions were always important). cjb> I was afraid you were going to say that. :) edmcnierney> Say which? mchua> So we *are* continuing 8.2.1 work, but not necessarily 9.1.0 work? I'm... sorry, edmcnierney, I'm still a little bit confused. cjb> That OLPC still wants to do everything it was doing before, but without any funding to accomplish it edmcnierney> cjb: No, that's not quite what I meant to say. cjb> Ah, sorry. mchua> Will OLPC be driving/managing software releases, just with volunteer dev labor? Or depending entirely on an independent upstream project (...somehow?) edmcnierney> No - it's my job to communicate :) edmcnierney> By "wish list" I meant to indicate that all the things we were saying were important we still think are important. I guess I'm reacting to the "OLPC dumps Sugar" headlines. But we need to figure out how to make it possible/easy for people who ARE able to move OLPC software development forward to do so. Jan 09 15:13:27 * julianob (n=julianob@201.21.203.138) has joined #olpc-meeting _sj_> hola edmcnierney> _sj_: Hi there. cjb> edmcnierney: ah, I see mchua> edmcnierney, do you have any wish list for the groups you'd like to see pick up that work? (Fedora, etc.) erikg> hi all mchua> (or a new one entirely) dsd_> thanks ed, that answers a lot of my curiousity :) edmcnierney> cjb: Am I helping (I'm feeling uncertain)? edmcnierney> I'm being inarticulate. cjb> edmcnierney: I jumped too quickly from what we wish might happen to what we're going to try to do ourselves cjb> it makes more sense now _sj_> (re: why me, better you, cjb. but I feel strongly about the importance of us all defining and committing to what and when 9.1 will be edmcnierney> cjb: Right - I don't want to send the message that we were making stuff up - the stuff on the 9.1 roadmap really was our best guess at what we thought was important/doable. It's no longer "doable" in the same sense, but we/I still think it's important. _sj_> and what to call if, if for any reason it should be renamed) _sj_> +1 edmcnierney> Maybe we can have a two-hour debate on what to rename it ;) erikg> edmcnierney: so i feel as if i spent months and months trying to get a change of focus about olpc software development, with the obvious result that i would be out of a job. now that i am i am unsure of what to suggest except that olpc use and promote existing, functional solutions while informing clients that an external organization exists to provide sugar support. edmcnierney> (thus avoiding doing any real work) dsd_> i vote we call it 'joyride' dsd_> least amount of work :) erikg> hah _sj_> you get bonus points for being pronouncable erikg> in what language? mchua> oh, I was going to suggest 'xkcd' cjb> so I feel fairly strongly that it would be folly to suggest that OLPC will be making that release dsd_> gregdek: are you here? edmcnierney> cjb: If you mean "something like what we've called 9.1 sometime in the first half of 2009" then yes, that absolutely agree. edmcnierney> I mean, I agree. mchua> So OLPC /will/ be guaranteeing an 9.1.0 release is produced in early this year. cjb> edmcnierney: I've been considering the idea that we should rename "9.1" to "Fedora 11" mchua> with... possibly a different feature set? edmcnierney> mchua: No, just the opposite. cjb> mchua: I think he just said the opposite of that edmcnierney> Whew - now I *am* communicating :) unmadindu> cjb: interesting idea :) mchua> oh. ohhhhhhhhhh. dsd_> cjb: that is kind of inline with erik's suggestion too, and something i have been thinking about Jan 09 15:19:02 * mchua parsed sentence backwards _bjordan> cjb: +1 mchua> OLPC will /not/ be guaranteeing a 9.1.0 release early this year. How about an 8.2.1? edmcnierney> We have a few things to do to complete the 8.2.1 release and we do need to make those happen. I think we have largely identified the means to do that. cjb> this idea comes from the hysterical hyperventilation that occurs when someone suggests that the 1-3 developers left should make a release all by themselve cjb> s cjb> I agree on 8.2.1; we can just finish that off. I don't think there's much controversy there. cjb> the nice thing about making our release be F11 is that Fedora actually has release managers edmcnierney> But beyond that, we (meaning OLPC in capital letters) has no ability/right to state - on its own - what a future release would look like or how it will happen. cjb> and bug triage teams cjb> and support resources cjb> and string freezes, and that kind of coordination Jan 09 15:20:46 * _sj_ has quit ("Leaving") erikg> wow, what a novel idea. use... an upstream resource mchua> Okay. I'm going to continue managing testing for 8.2.1 as a volunteer (and can now actually work on that, rather than running amok going "but what's happening? what's happening?" - 8.2.1 testing needs... a lot of love) dsd_> and it naturally brings along more workload reductions with it.. we can't fork packages, etc edmcnierney> HOWEVER - I do think it is very important that OLPC's remaining staff take responsibility for providing assistance to any interested parties wishing to participate in the evolution of XO software. Jan 09 15:21:02 * _sj_ (n=sj_@wikipedia/sj) has joined #olpc-meeting cjb> edmcnierney: this is why I'm so allergic to the idea of us making another release ourselves cjb> when you run out of resources, you need to make people depend on you less and less edmcnierney> cjb: Yes, I agree - but that means that the "assistance" we provide may be "go look at F11". erikg> seems there are resources to pick one or two types of tasks... either produce software or help people run whatever they need on their XOs _sj_> cjb: when you say 9.1 should be F11, do you mean that F11 should contain all of Sugar? erikg> _sj_: you know, it does already. sugar is just packages cjb> _sj_: that's stated ambiguously edmcnierney> cjb: And working on our own patches to F11/F12/etc as appropriate (upstreamed, not forks). _sj_> right _sj_> but the clarity involved in providing more detail would be productive Jan 09 15:23:04 * mchua is mildly confused; wouldn't switching to unmodified f11 cause performance issues? (but I'm probably not very well informed here) erikg> mchua: i have an unmodified f10 which boots on an xo erikg> without an SD card. all is well cjb> things can be "in F11" without being installed by def cjb> ault erikg> ok. minor mods... kernel and initramfs. cjb> and then a "Sugar spin" of F11 can exist erikg> yes _sj_> right. edmcnierney> mchua: There is a converging evolution between XO-specific Fedora and "stock Fedora". erikg> all that is required to enable it is build scripts, local tech, and global support systems cjb> mchua: ah, let me explain cjb> I'm not talking about running GNOME and everything in Fedora, like we did for the SD thing erikg> although that would work cjb> I'm talking about the system looking exactly the same as e.g. 767 cjb> but being obtainable from a straight Fedora release /worry>, I think I'm good now. mchua> thanks cjb. Jan 09 15:25:04 * mchua is here to ask the stupid questions ;) cjb> we are actually fairly close to this now! dsd_> one concern i have is that fedora really doesn't seem targetted for small, "embedded" systems cjb> here at fudcon, we are looking at every "fork" we have in koji against stock F10 dsd_> echoing one of mitch's recent comments cjl> Wger is localization of UI strings going to take place? cjb> and working out how to get rid of those forks _sj_> cjb: by 'obtainable' do you mean 'one script away from' ? Jan 09 15:25:25 * unmadindu_ (n=sayamind@gnu-india/admin/unmadindu) has joined #olpc-meeting _sj_> hiya unmadindu cjb> once the forks go away, we are where I'm describing dsd_> a large proportion of our forks have originated simply because Fedora goals and audiences are significantly different from our own cjb> _sj_: no, because that would be too inconvenient. more like, there are GNOME, KDE, and Sugar spins on Fedora 11 cjb> s/on/of/ unmadindu_> _sj_: hello cjb> dsd_: and a large number have recently disappeared because the Fedora folks are entirely willing to split out packages when that happens dsd_> cjl: UI stuff will be handled by sugarlabs cjl> dsd_: Not without a Pootle server. _sj_> cjb: it seems to me there might be a Sugar spin and a separate XOOS spin of Fedora 11. dsd_> _sj_: what would the difference be? _sj_> where the former is roughly the same size as a stock F11 installation _sj_> and can boot either Sugar or GNOME _sj_> (say) pgf> red herring erikg> strong recommendation of xfce. resource use is significantly lower @ runtime. pgf> the important thing is to recreate 767 from upstream fedora. _sj_> ok. erikg> yes pgf> only after that go to the dual thing. Jan 09 15:28:16 * marcopg (n=marco@dhcp-18-190-36-83.dyn.mit.edu) has joined #olpc-meeting _sj_> and ignore the semantics. _sj_> to put it a different way, there may be fedoran sugar lovers who are making their own spins not targeted for the XO. cjb> (sorry, flaky wireless) mchua> Ok - here's my current mental picture here of future software work, which may be wrong. _sj_> forgetting the herring, erikg raised a good point mchua> we're doing 8.2.1, which will be not-stock-f11 edmcnierney> mchua: Right. cjb> cjl: to answer your question, I would expect: sugar is translated in pootle -> sugar is submitted to fedora -> the fedora team does the release _sj_> earlier : which is there is a tradeoff between making it easy for XO users to install whatever os and software they like, and making it easy for XO users to install a steady procession of securely signed builds. Jan 09 15:29:53 * martin_xsa (n=martin@dhcp-49-123.media.mit.edu) has joined #olpc-meeting mchua> and then OLPC will... cause a build to happen that has the same features as 767, but is stock f11, plus whatever shiny gui stuff people want to put on top. mchua> at that point, Software Is Fedora's Problem. mchua> and OLPC is along for the ride. pgf> perfect. ship it. cjl> cjb will sugar PO files be allowed to remain on dev.l.o until n alternative Pootle server emerges from the ether? mchua> The bit I'm confused about is that the second build (the F11-like-767 one) - will that have the changes and new features that happened between 767 and 8.2.1? edmcnierney> mchua: Invite me to the party, too. cjb> cjl: if SL doesn't have a pootle server; well, that's the sort of thing we should fix soon erikg> what if the deployments want another distro? cjb> cjl: of course. mchua> should the f11-like-767 build be more properly named f11-like-8.2.1? cjb> erikg: that is fine cjb> I think our rough action items should be: erikg> ok. olpc just doesn't offer support for much of anything post activation dsd_> mchua: yes.. bear in mind that F11 doesnt exist yet either marcopg> cjb: erikos and sayamindu was talking about moving pootle to SL cjb> 1) rid ourselves of the OLPC monopoly on build signing/dev keys dsd_> mchua: its just a way of thinking, as i understand it edmcnierney> cjl: That's exactly the kind of "assistance" OLPC needs to keep doing (maintain Pootle server until transitioned). cjb> 2) at this point the deployments can do whatever they want. mchua> dsd_: noted, just curious whether the 8.2.1 features will also be targeted in this "everything goes to f11!" switch. (can't imagine why not but would like confirmation.) erikg> there are many ways to do this. i hope an efficient one is chosen cjb> 3) start pushing infrastructure out to the community anna_bham> Birmingham says "here, here" erikg> hi anna_bham mchua> cjb+infty cjb> this includes Pootle going to SL, git going to SL, packages going upstream to Fedora instead of in our dropboxes cjb> 4) start thinking about planning a release :) cjb> (I mean post-8.2.1) cjb> and when I say "planning a release", I mean "getting everything into Fedora in time for their release" edmcnierney> I think I thoroughly agree with cjb, and this afternoon he's being more articulate about it than I was. _sj_> cjb : who is working on 1) ? x>, so we need to get all our stuff in by then" cjb> _sj_: I probably would have hoped for cscott, but I'll try to subtitute for him with Mitch erikg> _sj_: depending on how you want to do it, it is either "almost done" or "developer months from complete" edmcnierney> _sj_: Mitch is, and we're currently under the impression that the ball's entirely in his court on that. _sj_> I mean socially... edmcnierney> (we meaning me, Mitch, and cscott) cjb> _sj_: sorry, I don't understand _sj_> if we are giving 10,000 groups the ability to sign builds cjb> edmcnierney: that's my understanding too _sj_> then we don't need to preserve the concept of 'signing' as a way to protect machines erikg> the problem appears to have left the building _sj_> if anyone at all can register to sign a build and do it the same day _sj_> then we could just deprecate the concept dsd_> do we still have 3ish full time redhat engineers helping us? edmcnierney> _sj_: You're probably a few steps ahead of the game, but that's OK. _sj_> mm edmcnierney> Right now the number of signing entities == 1. cjb> _sj_: oh, indeed! cjb> for example, antitheft marcopg> dsd_: I guess but I have no idea ;) anna_bham> Birmingham wanted to sign our builds but I couldn't get the key. We got all 15K dev keys instead for flashing. Jan 09 15:35:30 * unmadindu___ (n=unmadind@218.248.70.235) has joined #olpc-meeting cjb> my controversial suggestion for antitheft is that we tell countries that we're sending out all further laptops with security disabled edmcnierney> The first thing to do is to make that a smallish integer greater than 1. Then we can worry about getting to N. cjb> and we say "hey, here's some code you might like if you want to deploy a security server" erikg> cjb: sounds like the solution Jan 09 15:35:57 * unmadindu__ (n=sayamind@59.93.247.39) has joined #olpc-meeting cjb> (but that we aren't going to do that) cjb> I don't know if Nicholas will like that Jan 09 15:36:12 * mchua notes that test infrastructure will then also have to merge/migrate to fedora/sl - please hook me up with whoever is coordinating the infrastructure move, if there is someone. Jan 09 15:36:13 * edmcnierney is wondering why he is still needed, as is saying everything he would have said. Jan 09 15:36:14 * erikg applauds edmcnierney> as "cjb is saying", that is. Jan 09 15:36:31 * erikg is just a cheerleader now Jan 09 15:36:43 * mchua joins erikg in the "woo cjb" camp pgf> nice pompoms cjb> since it might affect his ability to sell laptops Jan 09 15:36:55 * erikg belly-dances mchua> *\o/* cjl> edmcnierney: FWIW, I've been getting lots of practice unwinding a complex computing environment over the past year, through a 25% RIF in March and a 55% RIF in Sept. with sale to Roche closing several days ago. Jan 09 15:37:05 * edmcnierney thinks NN no longer thinks very much about Gen 1 software one way or the other. erikg> cjb: well, not selling laptops at walmart is affecting his ability to sell laptops cjb> anyway. that's cjb's description of how we're going to solve all of the world's problems. can I bow now? :) edmcnierney> cjb: ta-da! mchua> *thunderous applause* pgf> applause+1 cjb> edmcnierney: but he cares about selling Gen 1 laptops, and countries are going to say "And they have antitheft, right?" edmcnierney> Actually, my role is to take the blame when NN does complain... Jan 09 15:38:04 * mchua offers to write this stuff up on wiki + post transcript post-mtg, btw - cjb, just poke me when all this is over. cjb> and my response of "They will if you write it" is probably not the response he wants to give cjb> mchua: thanks very much! edmcnierney> cjb: Absolutely! We'll just put an asterisk next it that says "available equipment", like the car manufacturers do. Jan 09 15:38:41 * _sj_ has quit (Read error: 104 (Connection reset by peer)) pgf> s/cjb/cjl, i think martin_xsa> mchua - I missed the 1st stage if this, so summary or log welcome mchua> cjb, so code/infrastructure transitioning seems reasonably well specced out, to me (or at least I can see how it might happen, and all) mchua> martin_xsa: noted, I plan on emailing devel and techteam when this stuff is up edmcnierney> pgf: I was referring to the "optional antitheft equipment available" feature. pgf> edmcnierney: ah. sorry. edmcnierney> pgf: I told you I was being inarticulate, no? mchua> cjb: how about transitioning the people, though? by that I mean how will local developers be... um.... encouraged? Jan 09 15:39:57 * mchua is inarticulate as well today cjb> oh, no-one pointed out the largest flaw in my plan of renaming 9.1 to Fedora 11 erikg> we go to where the deployments are happening and help them make it sustainable locally cjb> which is that we're in the middle of moving to F10 cjb> and F11 feature freeze is in two months edmcnierney> cjb: Well, it's hard to get there in time. Jan 09 15:40:30 * unmadindu has quit (Read error: 110 (Connection timed out)) cjb> and my plan requires that we now move to F11, pretty much immediately erikg> you know, debxo is working quite well... mchua> erikg: so "not OLPC's problem," basically? edmcnierney> ooh, I agreed with cjb again ;) Jan 09 15:40:36 * smithbone would personally like to rename it to "etch" cjb> except without the engineers we were using before dsd_> cjb: i didn't read into the "11" bit too closely... i think there are a lot of challenges involved, this will not be easy erikg> mchua: yes dsd_> definitely worth doing, but i'd have a really hard time putting any kind of timeframe on it cjb> mchua: I don't have great answers for that one, unfortunately martin_xsa> even if it's "f11", cutting down the bits of f11 is a ton of work Jan 09 15:41:26 * edmcnierney will motivate the Fedora development community by buying it beers and wings tomorrow night, and saying nice things about XO development. Jan 09 15:41:32 * _sj_ (n=sj_@wikipedia/sj) has joined #olpc-meeting erikg> martin_xsa: or building it up from scratch unmadindu__> sorry to butt in late, but considering that we might have certain patches which are specific to OLPC only, how do we integrate that with Fedora (considering that Fedroa feature freeze is pretty imminent) pgf> does the fedora build system allow for building up, rather than down? cjb> martin_xsa: I don't really understand cjb> unmadindu__: it's in two months, early March dsd_> one nice thing is that if we get 50% done for F11, that stuff automatically goes into F12 etc.. no need to repeat our work like we have to at the moment martin_xsa> we can reasonably count of fedora to carry all our packages, but our images are fairly cut down edmcnierney> I have been talking to gregdek about helping stimulate the small-but-growing Fedora-on-small-systems community. cjb> unmadindu__: we are trying to accomplish it today, at FUDCon. We are unlikely to succeed today, but we can get close. mchua> yeah, that was about to be my first suggestion - deploy gregdek. martin_xsa> pgf, either way, we are saying fedora will carry all our packages, so it's picking the subset pgf> dsd_: not completely true, since packages can regress. and do. martin_xsa> and making sure that subset plays martin_xsa> well with our hw edmcnierney> It's not clear to me what we get done in F11. My previous thinking (in talks with gregdek) is that the Grand Unified Distro theory is probably an F12 target. cjb> edmcnierney: ah. that is fine with me, of course -- I'm presuming you wanted a release earlier than that cjb> I think we're talking December or something, for F12? edmcnierney> I want a lot of stuff I can't pay for. martin_xsa> on fedora-on-small -- f11 is moving in that direction but the segment is cornered by debian :-/ cjb> martin_xsa: well, that's always been true cjb> f11's an awful lot better for small systems than f6 was edmcnierney> cjb: I last heard that (a) F11 was a May 25 target, and (b) future Fx releases might be a tad more than 6 months apart. So that's about the same thing. martin_xsa> i'm not particularly original :-) Jan 09 15:44:05 * mark____ (n=mark@pcp031231pcs.unl.edu) has joined #olpc-meeting cjb> edmcnierney: got it. cjb> yeah, the biggest problem isn't hitting the May date, it's hitting the March feature freeze cjb> having someone else handle the release process for us has a big downside edmcnierney> Right marcopg> edmcnierney: it seem to me that we are sort of forced into GUD for F11 now erikg> pgf: yes, kind've Jan 09 15:44:48 * cjl hopes edmcnierney has lots of beer money to spread around. . . cjb> which is that we can't tell them to slip it any more :) gregdek> edmcnierney: I think we may be closer to F11 than we think. cjb> marcopg: GUD? marcopg> cjb: Grand Unified Distro :) cjb> heh dsd_> gregdek: have you been reading? i'm interested on your take of these ideas Jan 09 15:45:17 * gregdek reads back. cjb> gregdek is repsonsible for many of them :) cjb> we've been talking about it here erikg> pgf: sorry, that was delayed erikg> it's possible to build up. it's just done so rarely that the builds that result are brittle Jan 09 15:45:43 * mark___ has quit (Read error: 60 (Operation timed out)) edmcnierney> marcopg: Maybe it should be the Freakin' Unified Distro, then. cjb> edmcnierney: I think I'm at a conference about that one Jan 09 15:46:08 * ke4qqq (n=ke4qqq@fedora/ke4qqq) has joined #olpc-meeting _sj_> marcopg, it sounds that way to me too _sj_> hiya ke4qqq martin_xsa> it's no GUD yet cjb> well, then, how about: cjb> 1) we try hard to get GUD in F11, with their release insert month here>", i don't think that really fits with our new community-based mentality mchua> cjb: with the 8.2.1 feature set, or 9.1? cjb> 2) if we fail, we say "hey, sorry" and fall back to F12 Jan 09 15:47:04 * eben (n=eben@dhcp-49-134.media.mit.edu) has joined #olpc-meeting dsd_> agreed marcopg> edmcnierney: :) Jan 09 15:47:21 * stickster (n=pfrields@fedora/stickster) has joined #olpc-meeting dsd_> i.e. it's ready when it's ready mchua> wait, dsd_ , why not? communities and deadlines aren't incompatible last time I checked... dsd_> which is the usual way that open source projects work cjb> edmcnierney: does that work for you? do you feel compelled (by our management and "customers") to make timely release? gregdek> dsd_: It depends on what the workload looks like. If most of the work is "twiddling bits to get them upstream," it'll be easier to get help from the Fedora maintainers of the equivalent packages. edmcnierney> I think my previous comment to gregdek was along the lines of, "We should try really hard to get everything into F11, but we realize that that almost certainly won't be 100%, so we wrap up the remaining bits in F12". Jan 09 15:47:47 * |tanya| (n=tanya@dhcp-18-190-60-36.dyn.mit.edu) has joined #olpc-meeting cjb> edmcnierney: but do we promise the F11 build to anyone in the meantime? _sj_> is the fallback 9.1 that is not entirely in f11 dsd_> mchua: its pretty rare in open source projects, in my experience _sj_> or an f11-based build that misses some of the features already worked into proto-9.1 ? gregdek> If we have a 9.1 that is 95% F11 plus a few outliers, that's not necessarily a bad outcome. dsd_> mchua: closest widespread thing is freeze dates, but that is different Jan 09 15:48:15 * unmadindu_ has quit (Read error: 110 (Connection timed out)) martin_xsa> mchua, meeting goals and dates usually requires a bit of funding marcopg> edmcnierney: but who is going to do the work necessary to ship F11 + customizations if we don't get there in time? dsd_> mchua: counter examples welcome though :) cjb> _sj_: you say "fallback" as if it already exists edmcnierney> I don't like to make promises over which I have no control! But we should be able to look at Sugar-On-F11-For-XO and (after completing security magic as above) make sure that anyone who might be interested in it know about it. cjb> the F10 joyride work is not currently usable cjb> we lost momentum on it a while ago, unfortunately erikg> why rebase marcopg> dsd_: both GNOME and Fedora ships on time based releases erikg> why rebase... i don't follow. if the user-facing product is not changing there is no reason to rebase. cjb> erikg: so that we don't have to make the release ourselves, because we can't afford to, because we have LIKE ONE FREAKING ENGINEER over here ;-) dsd_> marcopg: yes, but they dont say "we MUST finish X,Y,Z for their time based releases. if something doesnt make it in, the freeze dates do not change, and they have to wait for the next cycle edmcnierney> marcopg: I don't know. We might not have something we "ship", but which is available to a deployment that wants it. marcopg> cjb: all our bets are on you now! :) erikg> what i'm trying to say is that unless the rebase gets you more features you can take your time Jan 09 15:49:46 * mark____ has quit (Remote closed the connection) martin_xsa> marcopg, those projects have sponsoiring companies setting goals and dates... Jan 09 15:49:51 * pgf notes that cjb has always been too emotional. Jan 09 15:49:53 * mark___ (n=mark@markus.unl.edu) has joined #olpc-meeting edmcnierney> cjb: Hey, I write code, too! I think I have my COBOL coding forms around here somewhere.. _sj_> pgf :-) cjb> erikg: and I just described why to rebase even in the non-presence of features gregdek> IMHO: the "9.1 release" is probably mostly about reconciling a new process to onboard community engineers and take advantage of Fedora's preexisting release engineering process. martin_xsa> I'm with erik - rebases are optional mchua> dsd_: ah, no, you're right. I was thinking of freeze dates (which I think would be a good idea for OLPC, personally.) Jan 09 15:50:13 * smithbone hopes he's more than chopped liver marcopg> martin_xsa: sure, I agree with your point about that, was bringing it up at SL meeting this morning :) cjb> pgf: I can't tell whether you're joking. :) Jan 09 15:50:25 * apuch (n=wilee@dhcp-18-190-35-84.dyn.mit.edu) has joined #olpc-meeting marcopg> dsd_: sure martin_xsa> from past expereince - skip-one-upstream-release has always been the winner dsd_> mchua: freeze dates are easier to implement in more mature products Jan 09 15:50:42 * erikos (n=erikos@dhcp-18-111-46-111.dyn.mit.edu) has joined #olpc-meeting cjb> marcopg: the feature consists of not spending money on our own engineers martin_xsa> cause your patches land upstream always on current+2 martin_xsa> so I'd stay on F9, and head for F11 cjb> anyway, look, it's like this marcopg> my feeling is that we will have either to make F11, or skip until F12 if we don't make it in time martin_xsa> because our F9 patches didn't make it to F10. Jan 09 15:51:39 * typist (n=mark@dhcp-18-111-56-202.dyn.mit.edu) has joined #olpc-meeting cjb> we've outlined a plan about how you might be able to keep developing software even after you lay off almost all of your engineers martin_xsa> same happens with the XS marcopg> or marcopg> ship F11 with some regressions martin_xsa> same happened with all my moodle work in the pst... martin_xsa> past marcopg> which will be hopefully addressed in F12 cjb> (I consider being part of generating this plan to be the crowning achievement of my career so far, frankly, because the idea of continuining development right now is so manifestly ridiculous.) cjb> and, we can spend a while to think about that plan. we don't have to agree right now. martin_xsa> cjb, you've got several crowns to wear mchua> cjb: should we get all the concerns about whatever processes and problems have been proposed out on the table now? _sj_> yes. mchua> (or ask for them on mailing lists, or something) cjb> mchua: that's fine martin_xsa> so your dentist tells me pgf> cjb: i'm not sure whether you're joking. ;-) dsd_> marcopg: we might not make F11, but anything we prepare for F11 will automatically be in F12 (assuming we do it right, which we will), so its not like "skipping" cjb> pgf: touche :) gregdek> dsd_: Yep. dsd_> i say (once decided and agreed) we just get going on it and see what happens, at what time :) marcopg> dsd_: yeah what I mean with skipping is that we won't have a new release in May that deployments can use pgf> dsd_: sure -- what are they going to do, fire us? Jan 09 15:54:02 * mchua would like to request we make sure we're all running in vaguely the same direction first... dsd_> ah, yes dsd_> i agree, i dont think OLPC can promise a timeframe to deployments _sj_> marcopg, shipping f11 with some regressions might be sensible edmcnierney> dsd_: I'm certainly not going to promise anything. marcopg> _sj_: yeah, that's what I'd aim to _sj_> in that it encourages people who really care about a feature to spend their extra energy learning how to work it upstream cjb> _sj_: to what end? we haven't put any new features in yet martin_xsa> if we do ship F11 with regressions - it's better to ship F9 _sj_> martin, now I see what you meant cjb> I don't know on what grounds someone would possibly decide to run joyride instead of 767 in a deployment edmcnierney> dsd_: In fact, I'm trying to help communicate an anti-promise - please realize that we cannot promise things, so stop asking. _sj_> cjb, we mean regressions of features in 767 that might not make it dsd_> edmcnierney: :) marcopg> cjb: we will have put a huge feature in, i.e. mainteinability, at the cost of a few regressions cjb> oh! cjb> sorry, I was thinking of F10 _sj_> cjb: so, we could commit to an XOOS release which is entirely based on F11 _sj_> with a more or less fixed timeframe -- and a featureset determined by what gets into the march feature freeze martin_xsa> but maintainability is ... well it's ok if the laptops in the field skip a fedora release and upgrade from a F9-based XOOS to a F11 based one... erikg> marcopg: i don't see how maintainability falls out of the equation. is it just because cutting-edge is where the fedora devs are? _sj_> (here the timeframe is "given a f11-based codebase, how long does it take to make the XOOS spin") martin_xsa> in fact, I'll say something radical - both on laptop _and_ server, we want to work with gregdek to switch to the CentOS stable branch marcopg> erikg: fedora has full time developers that will ensure F11 is released (and in time), while olpc doesn't have them anymore :/ pgf> marcopg: oof. martin_xsa> to we kill the endless fire-and-motion churn of rebasing way too often as we do martin_xsa> now erikg> yes. but will fedora devote resources to this project? dsd_> _sj_: has a point.. we can promise to release *something*, it just might be unbootable or not fit on the NAND :) _sj_> pgf: you mean martin, right? pgf> martin_xsa: oof. bad completion. _sj_> dsd_ : the timeframe for XOOS 9.1 will be longer-after-F11 than the next release would be after F12. martin_xsa> fire-and-motion eats up a ton of resources and gives us very little now that the kernel stuff is mostly where we want it. erikg> yup marcopg> dsd_: I don't think it will be that bad... we was going through the packages today and while there is tricky stuff we are getting nearer quickly smithbone> martin_xsa: I disagree that the kernel is anywhere close to where we want it. pgf> martin_xsa: will centos/rhel be willint to split packages like we need them? martin_xsa> so if we switch from tracking Fedora to tracking RHEL or CentOS, a huge burden goes away. smithbone> Theres still a huge ammount of work to do on suspend/resume smithbone> Fast suspend resume that is. martin_xsa> ok - we can still carry some kernel patches, and track kernel a bit cjb> sorry, flaky wireless again cjb> I agree with everything everyone is saying martin_xsa> let's say- we'll always carry a delta pgf> smithbone: does no on else want that same work? _sj_> dsd_, I hope "make a spin that fits and boots" is not a blocking feature at this point! erikg> i already have a fedora spin which fits in the NAND, runs fine, and is just based on a list of packages yum-installed into a minimal chroot edmcnierney> smithbone: That's obviously a major area where we need to work to contribute to the kernel going forward. erikg> it has bugs but it works erikg> a fedora 10 spin martin_xsa> but our detla against F6 was ginormous erikg> so i don't see it as hard if you don't mind the bugs smithbone> pgf: Well few people have the hardware that allows it to work like we want. edmcnierney> pgf: I think others do, but probably few as much as we do. erikg> there were only two forks erikg> initramfs erikg> kernel martin_xsa> with the next RHEL/Centos, it'll be smallish, and we can pick and choose a few things to backport. cjb> Mainly what I'm interested in right now is edmcnierney saying that it's okay with him if we tell our deployments "You should run 767, and we might have something better in May, and if not we might have something better in December" dsd_> erikg: how big does it get if you "yum install sugar"? erikg> dsd_: haven't tried dsd_> erikg: would be interesting to know. would also be interested in how big the "bare" install is, as you have it now erikg> i was going to publish it this friday but being laid off distracted me dsd_> :( _sj_> martin_xsa, that sounds quite reasonable to me erikg> bare install, xfce base, minimal stuff, is 600 mb uncompressed erikg> and much less compressed erikg> maybe 400 martin_xsa> erikg, I'm a client for your build erikg> it doesn't use much of the fedora toolchain Jan 09 16:01:30 * _sj_ is too _sj_> erikg, we should invade fudcon tomorrow with machines running it. dsd_> thats impressive martin_xsa> will trade it for a few drinks of your choice dsd_> i hope you can find time to publish your work soon :) edmcnierney> marcopg: What I'm going to be saying is that 8.2.1 is what they should use/upgrade to when we release it, and that we will update the factory to start using that release, and going forward they should look to the next release to be a Sugar-on-Fedora spin for the XO. And that's a combination of software released by Fedora and Sugar Labs, not OLPC. erikg> dsd_: i have a repo but it's not completely up-to-date erikg> i can push right after the meeting dsd_> cool erikg> dsd_: it has some of the bugs i saw from your f9 sd card rebase (black menu buttons, specifically) erikg> but it is, in all appearances, a working system marcopg> edmcnierney: yup, that sounds good to me. (I hope we will be able to ship a 8.2.1!) erikg> i suppose this is slightly off-topic, but it helps to know that people are interested erikg> i have been lacking motivation since wed. edmcnierney> marcopg: I think we'll be in good shape on 8.2.1, mainly because the amazing mchua is still on the job! cjl> what is needed to finish 8.2.1 ? edmcnierney> But without a job... marcopg> yay for mchua! :) dsd_> erikg: well, the tables have turned as of this meeting cjb> edmcnierney: +1 on that erikg> dsd_: i am still trying to figure out how marcopg> I can try to help out with 8.2.1 too, if there is anything in sugar land that still needs to be done cjb> so, who's volunteering to create the olpc5 repo? ;-) edmcnierney> erikg: Bring it to FUDCon tomorrow and I'll donate my Flat Top Johnny's drink ticket to you. erikg> :) dsd_> erikg: ironically, because you lost your job? :( dsd_> cjb: i thought the point was to not do that? Jan 09 16:04:26 * dsaxena is now known as dsaxena_away edmcnierney> marcopg: Thanks for the offer. I think we're in good shape in that regard, but I need to get back to reviewing the trac bugs next week. cjb> dsd_: fair point dsd_> my vote for the starting point is to use fedora tools to make a rawhide spin that boots from SD cjb> dsd_: I think we'll need it for kernel/initrd/initscripts/etc dsd_> including sugar + gdm cjb> dsd_: gosh erikg> dsd_: the problem with the jffs2 boot is nash cjb> dsd_: so we abandom pilgrim, right? marcopg> edmcnierney: cool, let me know if you see anything there I can help with marcopg> cjb: can we do that? dsd_> cjb: yes, or get pilgrim accepted by fedora cjb> sure, I don't care erikg> once you bootstrap yum you can chroot and use it to build the whole system marcopg> dsd_: that's not going to happen, since livecd-tools replaces pilgrim dsd_> ok, then we uselivecd-tools dsd_> remember, fedora will be doing these builds, right? marcopg> dsd_: the prob is that livecd-tools doesn't provide all that we need dsd_> so they use the tools, not OLPC erikg> to be blunt, seems like the fedora tools are hindering development. marcopg> mainly initrd/security stuff needs to be dealt with erikg> esp. on small systems. dsd_> this isn't going to be easy Jan 09 16:06:39 * mchua is officially announcing Slackerdom on 8.2.1 until the weekend passes - I have a lot of things to go through, but will be back on Monday with updated QA stuff for 8.2.1 (finally) marcopg> (and jffs2 but that's easy) dsd_> but its something we have to work with fedora on cjb> marcopg: well, at least we're at a conference full of people of know something about the problem _sj_> marcopg, actually : coordinating bug review (8.2.1 and 0.84) is important. erikg> dsd_: right marcopg> cjb: excellent point, we could try to hack that up here _sj_> and edmcnierney, we're avoiding the question of how/where feature requests for 9.1 and from deployments go _sj_> and get triaged. pgf> erikg: when you say you can bootstrap with yum -- that's in a chroot, or mock, or something like that? _sj_> including xo-specific kernel requests erikg> pgf: in a chroot on any linux _sj_> and related integration work pgf> erikg: cool. erikg> pgf: the rinse stuff just depends on rpm. which is ported everywhere. it just gets you to a bootstrappable system. mchua> marcopg, want to have a big happy bug upstream/downstream sprint with simon and such during xocamp sometime? fedora, olpc, and sugar all in one room, chugging edmcnierney> _sj_: I think part of OLPC's job going forward is to collect that input and communicate it to the Fedora / Sugar Labs communities as appropriate. Our value is being a good source for that field input. ... package list> _sj_> mchua, you're on the schedule for that monday? I think erikg> then hacks, etc. Jan 09 16:08:22 mchua marcopg martin_xsa m_stone mark___ meeting mvn071 mchua> _sj_: that's the mchua and edmcnierney show (basically, this convo, but for QA) not the big work sprint, which is currently not scheduled as I made it up 1 min ago _sj_> edmcnierney, so we need a stream of XOOS bugs and requests for each XOOS spin erikg> edmcnierney: with the eventual goal of direct communication between deployments and sugarlabs/fedora? _sj_> even if the delta between that and F11/12/&c grows smaller each cycle _sj_> maybe those bugs all go to the XOOS maintainer and most of them are passed through Jan 09 16:09:39 * mchua has to pop out, make sure paperworks are all okay edmcnierney> erikg: I think direct communication is fine - no reason to get in the way - but some deployments will find it easier/preferable to talk to OLPC, so we should be responsible for passing on that information. erikg> i fail to see the value add of olpc in this case. if so heavily understaffed in the support and technical side of things, then the best long-term plan is to move users directly into the upstreams we are drawing from. erikg> otherwise customers will continue to wait. Jan 09 16:10:17 * skierpage (n=skierpag@76.14.64.22) has joined #olpc-meeting erikg> they may feel comfortable now, but as they understand what has happened here i doubt that sentiment will remain. edmcnierney> erikg: This is an important part of Reuben's job. _sj_> re skier pgf> erikg: as the h/w vendor, i suspect we'll always have a role. erikg> yes, of course erikg> pgf: a lot of h/w vendors produce products that end up running linux just because they are popular edmcnierney> pgf: You don't mean to say we're a laptop company?! erikg> but i understand the point pgf> edmcnierney: just channeling nicholas... _sj_> and many higher-level feature requests are simply "extracting use cases from users and converting them into requests/features that can be implemented in software" cjb> moment, jeremy erikg> pgf: hehe edmcnierney> pgf: Thanks for that. cjb> is here erikg> _sj_: that's really not something that olpc seems to want to do. cjb> I think we're going to walk around banging on heads until everyone solves our problems _sj_> which are not necessarily related to sugar or XOOS. erikg> sounds like the time has come to *strongly state* that we only support windows. that is a sure recipe for technical support from linux users. dsd_> this is a fantasic opportunity to grow the fedora-olpc SIG wotsit _sj_> yes, eh wot? edmcnierney> cjb: Should we adjourn? I think we're largely in sync here. cjb> yes, I think so Jan 09 16:12:22 * erikg would agree cjb> I'll come over soon dogi> +1 cjb> to say goodbye to people pgf> what's xocamp about? edmcnierney> And mchua will make notes for us to edit. edmcnierney> pgf: About Monday morning. cjb> jeremy is enumerating the things we need to do to get fedora build tools working erikg> seems like we're going to talk about how to work without olpc anymore erikg> at xocamp. it seems very likely. _sj_> pgf, partly a continuation of this discussion cjb> erikg: yup! _sj_> partly a discussion aout how to process the feature requests and input received that has been translated into 9.1 planning cjb> erikg: that would be a good result in my eyes _sj_> (the parts that erikg thinks olpc doesn't seem to want to do :-) edmcnierney> pgf: We're going to spend time on Monday talking about going forward much along the lines of this conversation. Jan 09 16:13:32 * martin_xsa wants to get on a more stable upstream... erikg> cjb: and mine too. that discussion has my support. pgf> okay. what time? i suppose its on the wiki... _sj_> martin_xsa, can you add an xocamp topic about CentOS? edmcnierney> And we've got some folks traveling here to talk about interesting stuff, and we should take advantage of their generosity as much as possible. erikg> martin_xsa: i think dos development has been very stable for some time now _sj_> pgf: light breakfast is at 9 Monday dsd_> i think we need a fast moving upstream. we have a lot of work to get done to make this a reality martin_xsa> erikg, we can base it on Debian Potato _sj_> erikg, Potato is known to be much more stable erikg> until it grows six eyes _sj_> ok, thanks cjb. _sj_> most of us are in the office atm. erikg> thank you cjb cjb> see you all in a few mins martin_xsa> _sj_, there's alreadyt a "rebase" talk at xocamp martin_xsa> for the F10 rebase. probably a good venue to discuss cost/benefits and strategies around rebasing... _sj_> yes, it's specifically about f10?! cjb> (F10, or F11?) _sj_> we should add F11 and centos cjb> bwuh? mchua> cjb, I'm gonna take that as an #endmeeting and end transcripting