Hi,
Here are the TODOs from the meeting:
** TODO: jeremy to build table of sugar activities and other packaging work items on the Fedora wiki ** TODO: Various people to take items from that list and package them ** TODO: jeremy to go to 1cc, revisit next week. ** TODO: rnorwood to track down the squeek/etoys licensing issues ** TODO: gavin to track down the squeek binary blob issue ** TODO: rnorwood to send out minutes
Next Meeting: 1700 UTC / 1pm Eastern US time Friday, Aug 15
Here is a rough IRC transcript. I tried to break things out by topic and clean up some chatter.
<gregdek> I spent the week at OLPC HQ in Cambridge... <gregdek> (yes, cjb, can you do that? thx) <gregdek> ...and learned a whole bunch of stuff, and articulated some goals a bit more clearly. <gregdek> So I'm going to throw out a couple of projects that I think could be (relatively) low impact and (relatively) high reward, and then open the floor for discussion about what it'll take to get there.
** TOPIC: Sugar spin for Fedora, including bootable live CD.
<gregdek> POTENTIAL PROJECT #1: The Sugar spin for Fedora, including bootable Live CD. <gregdek> WHY? Because there aren't enough developers who can just take Sugar for a spin without lots of bizarre incantations. <gregdek> By building and maintaining the Sugar packages in Fedora (and elsewhere, but we care about Fedora) we can dramatically expand the "geek user base" and thus the potential developer base. <gregdek> So that's the goal. <gregdek> ...let's dig into that.
<jg> a piece of this project is helping marco with packaging of sugar, and testing.... <jeremy> that's actually probably one of the bigger pieces to be honest
<gregdek> We've got people already digging into building Sugar packages. <jg> first step is that sugar becomes another desktop like gnome or kde, and you log into sugar.
<gregdek> First step is that we get all the important packages built. :) <jeremy> gregdek: very much so
<jg> "yum install sugar" should be the goal ;-). * jeremy has started making some progress there <jeremy> jg: 'yum groupinstall sugar-desktop' but yes :)
<jg> marco has the base packages packaged; but activities are not packaged as rpms'.
<rnorwood> the wishlist is currently here: http://fedoraproject.org/wiki/PackageMaintainers/WishList#OLPC_Wishlist <gregdek> Actually, this list represents multiple projects, and I wonder if we should be breaking them out and tracking each project's needs separately. <gregdek> For example: <gregdek> * XS packages <gregdek> * Fedora on XO hardware packages <gregdek> * Sugar on Fedora packages
<gregdek> So the next question: is the current wishlist-on-wiki mechanism the right one?
<gregdek> Is it true that SL is trying to create different levels of Sugar activities to indicate relative levels of stability? <cjb> Hm, don't think that's been ratified properly. But we've certainly struggled with that question in lots of places. <cjb> For example, just for OLPC -- which activities should OLPC "support"? <jg> as few as possible ;-)... <gregdek> My sense is that some activities are "core" to the sugar experience and should definitely be prioritized. <jg> and as many as necessary ;-) <gregdek> journal, browser, pippy, for example. <gregdek> jg: You are a master of policy declaration. ;) <cjb> Yeah. We've sort of used the list activities we shipped with the original G1G1 as that list of "core", but not all of them are actually maintained. <gregdek> Doh.
<gregdek> So I assume that there will exist, at some point, a set of guidelines for what are "supported" and "unsupported" activities that fall out of Sugar Labs discussions. <gregdek> But until that point, what's our policy? <gregdek> "Package what we can find tarballs for"?
<cjb> gregdek: It's a bit of a bone of contention, but the G1G1 set seems agreeable. (And I think it's what's been packaged already.) <unmadindu> gregdek, cjb: or as a priority, we might want to package whatever is there in http://sugarlabs.org/go/ReleaseTeam/Roadmap#Fructose_Modules <cjb> unmadindu: yup, looks right <jeremy> unmadindu: that's probably as good of a starting place as any
<gregdek> Don't we have packaging guidelines for activities already for activities on the Fedora wiki? <rnorwood> gregdek: http://fedoraproject.org/wiki/Packaging/SugarActivityGuidelines <rnorwood> gregdek: the language issue that jeremy pointed out on the ML being the biggest issue, It hink. <jeremy> rnorwood: there are a couple of other things that feel like they could be better after doing a couple of pakcages. once I have a few more done, I suspect I'll have a better feel for "right"-ness <jeremy> gregdek: that's required for inclusion in fedora <gregdek> So we're basically packaging these directly from the source. Which means we are making rpms rather than xos. <rnorwood> gregdek: I think in fedora terms, we just ignore the concept of .xos <gregdek> I think that has to be right.
<cjb> Yeah. :) There have been "why not make .rpm be the .xo file format?" discussions, I don't recall the outcomes. <jeremy> cjb: and while that seems an interesting discussion, perhaps a tangent for this meeting :)
<gregdek> So let me spell out the simple action items so far: <gregdek> * Split out the wishlist into appropriate package sets (XS, Fedora for XO, Sugar for Fedora, activities) <gregdek> * Point folks in the wishlist to Fructose/Sucrose list and activity packaging guidelines
<pgf_> so this means there will be two formats used for installing activities? rpm and xo? (i'm just trying to understand.) <gregdek> pgf_: It's a fair question. <gregdek> pgf_: Users will always have the option to install .xo files locally. <jg> pgf_: for a conventional fedora desktop, you'd like to be able to do a yum install.... <pgf_> okay. i'm convinced. :-)
<gregdek> One other thing: <gregdek> Is it possible to associate a date with the wishlist items, so we know which stuff has just been sitting, if it comes to that? <gregdek> Or is that overkill? <rnorwood> gregdek: It's good practice to include a date, yeah. <jg> heh. I think it makes sense if someone's name is also attached.... <gregdek> Well, that's where I was going next... <gregdek> :) <gregdek> Or at least be able to say "unclaimed" or something. <gregdek> We edge closer to trac tickets with every data field we add... but I'd kind of like to hold off yet. :) <rnorwood> gregdek: so when you start work on 'something', attach your name and date. Add links to issues/bugs/discussion as needed, and remove it when it's accepted into fedora. * jeremy is making a table for the activities that should help... <gregdek> Thanks, jeremy. :) <gregdek> Hey jeremy, since you're building the table, do you want to do the initial sort of the packages too? <jeremy> I'm trying to do that too <gregdek> Very good. * gregdek writes down "jeremy" in the big book of TODOs. <gregdek> So down the line, once we've got these packages in...
** TODO: jeremy to build table of sugar activities to package as work items.
<gregdek> ...the next question is "what needs to happen to allow us to boot Fedora into Sugar instead of GNOME/KDE/xfce/wtfwm? <gregdek> Can we add this feature to the F10 roadmap? <jeremy> gregdek: it should be easy to do when we update the sugar packages. I can work with marco to make sure it happens <gregdek> Needs a feature owner. jeremy, will that be you, too? <rnorwood> gregdek: but the feature is a little bit more than GDM. <gregdek> rnorwood: Such as? <gregdek> Maybe someone needs to write a feature spec. <gregdek> Someone who volunteers the notion that "the feature is a little bit more than GDM," maybe. <rnorwood> gregdek: well, just 'make sugar work' and the other stuff we're already planning to do. <rnorwood> gregdek: 'sugar works and a reasonable set of activities packaged' <jeremy> I can probably throw the start together and then make rnorwood help ;) <gregdek> ...my take: if the feature is "allow GDM to boot Sugar in F10," that sort of encapsulates all the rest of the work, yeah. <gregdek> ...I kinda think that covers must of the "Sugar on Fedora" ground, amirite? <rnorwood> gregdek: yup. Jeremy to do initial feature page, and press-gang rnorwood to help
** TODO: jeremy to build initial
** TOPIC: Fedora on the XO <gregdek> WHY? Because Sugar isn't "there" yet for a large segment of the XO/G1G1 userbase, and despite numerous warnings that it's "not a laptop project", people continue to expect it to be a standard laptop. <gregdek> Which means that we're exploring dual-boot options of "Sugar" or "some minimal straight Fedora". <gregdek> Which means that we need to build a "minimal straight Fedora" that actually boots on the XO. <gregdek> Which depends on people who have the hardware! <jeremy> which depends on people that have the hardware
<jeremy> the thing that I don't entirely understand (maybe because I haven't played with the hardware as much) is why this really entails any sort of separate spin <jg> rnorwood: the problem is, then our friends in redmond have another weapon. <jeremy> and isn't just people making sure the hardware is well supported in fedora <jg> jeremy: size. <gregdek> Other than a different kernel and some dependency breakdowns... <jg> jeremy: RAM usage of some apps. <gregdek> ...but maybe this is an opportunity to break down some deps in Fedora itself. <jg> jeremy: audience.... <sdziallas> gregdek: yeah, definitely! <gregdek> Like the fact that PersonalCopy-Lite is the biggest package in the spin currently. :) <jeremy> jg: RAM usage of the apps -- fix the apps, don't skirt the issue by forking things <jg> jeremy: somehow, fixing evolution ain't going to happen overnight.
<jg> jeremy: I need something *quickly*. <sdziallas> gregdek: I was able to ship around this libgweather stuff (it was NetworkManager-gnome related), but this one could be fixed, too <jeremy> and if the idea is that people with a g1g1 think that the xo is a laptop and expect it to act like one, then they're going to just expect fedora to *WORK* <jeremy> not go use some weird off to the side thing <bryan_kearney> sdziallas: on a side note, could you send me the kickstart file? bkearney@redhat.com? <sdziallas> bryan_kearnay: sure :) <jg> jeremy: we have at least two alternatives for mail: thunderbird and claws. <gregdek> I think that there's the ideal, and then there's the pragmatic.
<jg> evo is not required. <sdziallas> jg: agreed! <jg> and it will send an interesting message to the evo folks ;-). <gregdek> The pragmatic: we must provide *something* that is more familiar than Sugar. <jeremy> jg: both of which are similarly bad in memory usage to evo (or worse in some cases). I've used them all :( <rnorwood> so - 1) Hardware support/kernel, 2) Install size/deps, 3) RAM usage of some apps/evolution sucks <gregdek> Even if it's not the best Fedora experience one might otherwise have. <jg> jeremy: but evo comes with 50 meg of help png images: we can't afford the flash load for evo.
<rnorwood> what about gnome/xfce <rnorwood> ? <jg> jeremy: need a "run out of flash" option. <gregdek> The spin sebastian made was xfce-based. <cjb> I think we're going to want GNOME <jg> rnorwood: that is another option. <rnorwood> (vs) <cjb> oh :) <gregdek> :) <sdziallas> bryan_kearnay: e-mail's out <sdziallas> well, I'd have wanted, too <gregdek> So here's my question. <jg> first thing to do is to get one working, and look at the RAM footprint. <cjb> I'd like the full NM applet, full i18n, that kind of stuff. <gregdek> Can straight Fedora work, if the kernel issue is sorted? <jg> heh. <jeremy> jg: it depends on what you're targeting as to what the need is <cjb> plus we know a lot more about hacking on GNOME than on xfce, speaking for the people in this channel. <jg> Ii8n is another problem. <jeremy> jg: if you have more you're not saying that flows into the need, I'm ears :) but nothing that's been said thus far really sounds like that's the case <jg> turns out that the stock fedora CD space is is dominated by eastern fonts and input methods. <cjb> I don't want to end up in a situation where we get xfce and then we get feature requests on high to add features to xfce that GNOME already has :) <sdziallas> well, when doing the test runs on my machine here, every gnome-based image was at least 100 mb larger than the xfce-based one <gregdek> cjb: -EINGNOMEALREADYWONTFIX
<gregdek> I just want us to get to something that boots. <gregdek> That's the first step. :) <cjb> that'd be a good start, indeed. <jg> jeremy: the same people who buy and OLPC thinking it is a conventional laptop (despite our warnings) are the kind that want something a bit more than xfce (at least when I've played with it). <jg> gregdek: I agree entirely. <jg> that's the next step.
<jg> now we know we can build spins that are acceptably small.
walters< That was quick. ;-)
<rnorwood> walters probably has some feedback about gnome-vs-xfce on fedora-XO spin <gregdek> jeremy is coming to 1cc next week! <cjb> yay! <gregdek> That's the resolution. You guys can slug it out. Just get something that boots plz, kthxbye. :) <jg> sounds good. <walters> if anyone comes up with any hard data on why/how xfce is smaller please do let me know <jeremy> and greg is now a lolcat <jg> walters: I suspect icon files. <jg> I haven't gone and looked carefully. <gregdek> hai! can i haz bootfedoraxo? <walters> jg: elaborate? <rnorwood> walters: this is just a preliminary discussion, not 'decision time', fwiw <jg> there are png files for several sizes of all the icons. <sdziallas> walters: fewer deps. <jg> we can pick just one. <gregdek> Yes. <jg> and nuke the others. <gregdek> We can just pick one. <sdziallas> jg, gregdek: +1 :) <gregdek> When the time is right, we can do all these things. <cjb> By the way, dwmw2 boots stock Fedora on external USB hard disks.
<gregdek> Oh, he does, does he? <cjb> so I don't think there are any large obstacles. someone mentioned a kernel problem of some kind? <gregdek> I wonder why that didn't work for us? <jg> heh. <gregdek> Maybe we just used the wrong incantation. <jg> different incantations. <jg> I'm not an OFW incantation expert. <cjb> yeah, seems like it should have worked, with F9. <cjb> ah, that might be it. <jg> cjb: no, some stuff went in after F9. <gregdek> All right. <jg> to kernel.org. <gregdek> I think the devil is in the details here... <jg> I betcha you need an updated kernel. <gregdek> ...and I think we can trust jeremy to sort these out in 1cc next week and report back next Friday? <jeremy> bah, who runs f9 anywya? rawhide everywhere! <cjb> maybe. you could even just use our kernel. <jg> and our kernel still carries patches not yet in kernel.org. <jg> that's the plan. <gregdek> Brillianr. <gregdek> t. <jeremy> cjb: or maybe you could just use ours ;) <cjb> we should also talk about getting a Rawhide OLPC stream at some point. We're on F9 now, but we can rebase to F10 for our next release (due around Christmas, I guess) <cjb> jeremy: we're trying! <gregdek> Heh. <jg> ofw2 will probably make it much easier for a generic linux kernel to "just work". <cjb> I think everything to enable booting an XO on stock distros is upstream now <gregdek> OK. <jg> but right now, it won't. <gregdek> So... <cjb> which is a pretty big step, it took a lot of work, we have custom display hardware and all that stuff --- stickster is now known as stickster_mtg <jg> cjb: but you still have to build for OLPC.
** TODO: jeremy to go to 1cc, revisit next week.
** TOPIC: Squeek/etoys licensing.
<gavin_> VPRI believes that they have done enough work to change the licence to MIT, <gavin_> Will Red Hat legal except that, or ....? <jg> gavin_: there is *no* license issue for squeak now, I'm aware of. <rnorwood> gavin_: spot is The Legal Contact. <gregdek> Yeah, so what are we talking about? <jg> the last sillyness is that squeak has a binary blob, not rebuilt each time. <gregdek> Right. <gregdek> That's the real pain, from what I hear. <cjb> likewise. VPRI say it's now BSD-licensed, I don't see who we are to argue with them. <gregdek> Do we know why that is? <jg> said binary blob can export every line of smalltalk that is in it. <cjb> gregdek: it's just the development style. it's a feature. <jg> so it is sillyness of people who don't understand about smalltalk. <m_stone> gregdek: they come from a different school of programming. <jg> or similar environments. <cjb> they have total introspection of the blob, so they don't feel a need to rebuilt it from scratch very often. the blob is the preferred format for modification for them. <gregdek> Right. <gregdek> Which our packaging standards totally don't account for. <cjb> I don't think there's any legal issue here, just some people find it distasteful that they can't diff it etc. <jg> people who've never seen introspection, don't comprehend. <gregdek> So when you can actually create all source on the fly from the binary, you are by definition shipping source? <gregdek> Is that the contention? <rnorwood> So are there tarball releases of squeek/etoys that say "I am MIT (or BSD) licenced"? <jg> the binary *is* the source. <jg> rnorwood: I believe so. <cjb> gregdek: I think there is source available too? It's just that the interpreter isn't created from it each build. <rnorwood> Or an SCM we can pull from? <cjb> rnorwood: Absolutely. <jg> rnorwood: the scm is *inside* the squeak environment. <cjb> rnorwood: The problem is that VPRI had a handful of decades-old contributors that they couldn't get agreement to change the license from. <rnorwood> cjb: Ok - put it on the wishlist page ( http://fedoraproject.org/wiki/PackageMaintainers/WishList#OLPC_Wishlist ) <jg> it is entirely self-contained. <cjb> And they decided, given like 490/500 people who agreed to the change and 10 who were uncontactable, to go ahead and change the license. <gregdek> I don't even know how to begin to tackle the packaging issues. Maybe someone can get this issue in front of FESCO? <cjb> I think spot was dubious that that was legal. <rnorwood> cjb: Yeah, that may or may not be a problem. Spot is the guy we need to interface with to get legal to make a call. <jeremy> cjb: that's pretty dubious <gregdek> So it comes down to: <cjb> jeremy: They'd be happy to rip out those people's code if they complained. <jeremy> cjb: unless the contributions by those ten people are insignificant/obvious <rnorwood> cjb: So Red Hat legal makes those calls for us. <cjb> jeremy: I don't think any of them were major contributions <jeremy> cjb: the problem is that you have to assume they complain and rip the code out <cjb> rnorwood: yeah. so, that's the problem, anyway. <cjb> if I were a lawyer, I'd say "don't possibly do anything that sort of contributes risk to someone" <gregdek> So it's a matter of comparing Fedora's risk profile with VPRI's. <rnorwood> cjb: ok - how about you, jg, and anyone else who wants to be on the Cc send me your email address and I'll start a conversation with spot about it. <rnorwood> cjb: and see what he thinks the best way to proceed is. <cjb> rnorwood: sounds good <gregdek> OK. Thanks, rnorwood. <jg> rnorwood: bert freudenberg is the other person to be involved, on the VPRI side. <gavin_> me too they've been working on for 20 years and then have some random other group tell them they aren't allowed to :) <gregdek> Well, it's tradeoffs, isn't it? <gregdek> "Hey, we'd like to make your software available in one click to millions more users. Accept or deny?" <jeremy> cjb: they can do whatever they want, but that just means that it can't be in fedora <cjb> nod.
cjb< hey, what's your email addy so I can Cc: you on squeek/etoys license issue
<gavin_> I was planning on takeing the squeak blob issue to FONC ... <gavin_> does any one think that's unnecessary? <gregdek> Maybe wait for legal to come back? <rnorwood> cjb: well, if the answer is 'Our lawyers say this is legally dubious, let us help you rip out the offending code...' <jg> jeremy: the've been leaning over backwards as it is; but people who don't bother to comprehend that environments like smalltalk are built in fundamentally different ways than UNIX/Linux and complain they are different (and they started first!), I have less patience for. <gavin_> don't conflate the legal issue with the blob issue. <gregdek> Agreed. <rnorwood> gavin_: sure. <jeremy> jg: the blob issue is different from the licensing one <gregdek> If you want to attack both separately, that's fine. <gregdek> But understand that progress on one blocks implementation on the other.
gavin_< Do you want me to Cc you in convo about the license issue? If so, what's your email addy?
* jeremy knows he does not know enough right now about the blob to say anything intelligently one way or the other <gregdek> Doesn't mean the issues can't be worked in parallel. <gregdek> Just that there's risk that such work might end up useless. <rnorwood> gregdek: +1. gavin_ to drive the blob issue, /me to drive the license issue. <cjb> yes, the blob thing sounds like a non-issue. Some grumpy Debian people said that if it can't be diff'd it's not "open source", which is ridiculous. <gregdek> Heh. <gregdek> Let's try to be more reasonable than that. ;)
** TODO: rnorwood to track down the squeek/etoys licensing issues
** TODO: gavin to track down the squeek binary blob issue