Software discussion 2009-01-09

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. maintainability, 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 default
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
       an 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 is here
erikg>    pgf: hehe
edmcnierney>    pgf: Thanks for that.
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