Meeting Minutes Friday, August 08 2008

[Robin Norwood]

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 at 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

-- 
Robin Norwood
Red Hat, Inc.

"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching