Software discussion 2009-01-09: Difference between revisions

From OLPC
Jump to navigation Jump to search
Line 119: Line 119:


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

[[Category:Software]]
[[Category:Meeting minutes]]

Revision as of 06:29, 24 February 2009

Short version

This meeting was about plans for how OLPC software will work given the recent staffing changes.

cjb: we've outlined a plan about how you might be able to keep developing software even after you lay off almost all of your engineers (I consider being part of generating this plan to be the crowning achievement of my career so far, frankly, because the idea of continuining development right now is so manifestly ridiculous.) and, we can spend a while to think about that plan. we don't have to agree right now.

The situation

See http://blog.laptop.org/2009/01/07/refocusing-on-our-mission/

Some questions: does OLPC ever want to make another software release? Why? Is that compatible with laying off basically the entire engineering team? And so on.

Although OLPC can no longer fund software development the way we were, our "wish list" for what software might be on our machines hasn't materially changed. We're just no longer in a position to make those wishes come true ourselves (or less so, in that volunteer contributions were always important). By "wish list" I meant to indicate that all the things we were saying were important we still think are important. I guess I'm reacting to the "OLPC dumps Sugar" headlines. But we need to figure out how to make it possible/easy for people who ARE able to move OLPC software development forward to do so.

How this affects our previously planned releases

The nutshell: we finish 8.2.1 as planned, and merge into F11 (or F12, if not finished by F11-time) for future software releases; at that point, Software Is Fedora's Problem and OLPC is along for the ride.

Yes 8.2.1 release

8.2.1 is happening, and development will consist of incorporating features into the current software that we have (no fedora rebase yet). Roles remain the same; Ed will continue being the release manager, and Mel will continue being the test manager (as a volunteer).

No 9.1.0 release

OLPC will not be guaranteeing a 9.1.0 release early this year.

Beyond 8.2.1

Beyond that, we (meaning OLPC in capital letters) has no ability/right to state - on its own - what a future release would look like or how it will happen.

It is very important that OLPC's remaining staff take responsibility for providing assistance to any interested parties wishing to participate in the evolution of XO software. The "assistance" we provide may be "go look at F11".

Grand Unified Distro (GUD) Theory

Proposal: Move rapidly towards shipping straight Fedora, putting development efforts towards making Fedora into what we want to ship (working on our own patches to F11/F12/etc as appropriate - upstreamed, not forks).

The nice thing about making our release be F11 is that Fedora actually has release managers, bug triage teams, and support resources, and string freezes, and that kind of coordination. It naturally brings along more workload reductions with it.. we can't fork packages, etc

We're not talking about running GNOME and everything in Fedora, like we did for the Fedora-on-XO-on-SD thing. I'm talking about the system looking exactly the same as e.g. 767 (or 8.2.1) but being obtainable from a straight Fedora release. Let's call this Fedora-8.2.1, a recreation of the build from upstream fedora.

So what we previously called the "9.1 release" is probably mostly about reconciling a new process to onboard community engineers and take advantage of Fedora's preexisting release engineering process.

Current progress

edmcnierney has been talking to gregdek about helping stimulate the small-but-growing Fedora-on-small-systems community.

Here at fudcon, we are looking at every "fork" we have in koji against stock F10 and working out how to get rid of those forks. once the forks go away, we are at Fedora-8.2.1.

ericg already has a fedora 10 spin which fits in the NAND, runs fine, and is just based on a list of packages yum-installed into a minimal chroot. it has bugs but it works. there were only two forks, initramfs and kernel. bare install, xfce base, minimal stuff, is 600 mb uncompressed, and much less compressed, maybe 400; people are very interested in testing this and erikg will push updates to repo.

On scheduling

Try for F11 (May). We'll probably not make it, but we can clean up for F12 (Dec) as anything we prepare for F11 will automatically be in F12.

There may be some regressions of features in 767 that might not make it in to the first rebase. We will have put a huge feature in, i.e. mainteinability, at the cost of a few regressions.

Counterproposals

but maintainability is ... well it's ok if the laptops in the field skip a fedora release and upgrade from a F9-based XOOS to a F11 based one... in fact, I'll say something radical — both on laptop and server, we want to work with gregdek to switch to the CentOS stable branch. with the next RHEL/Centos, it'll be smallish, and we can pick and choose a few things to backport.

Using fedora build tools

...will be a challenge.

  • use fedora tools to make a rawhide spin that boots from SD
  • get Pilgrim accepted by fedora (or we'll have to abandon it)
    • use livecd-tools? (from Fedora)
    • the prob is that livecd-tools doesn't provide all that we need
    • mainly initrd/security stuff needs to be dealt with
    • its something we have to work with fedora on
    • well, at least we're at a conference full of people who know something about the problem
  • jeremy is enumerating the things we need to do to get fedora build tools working

Questions and Concerns

  • fedora really doesn't seem targeted for small, "embedded" systems
  • Where is localization of UI strings going to take place?
    • At Sugar Labs. Pootle will migrate there.
  • a large proportion of our forks have originated simply because Fedora goals and audiences are significantly different from our own. Will we be able to eliminate them?
    • counter: a large number have recently disappeared because the Fedora folks are entirely willing to split out packages when that happens.
  • antitheft: we could tell countries that we're sending out all further laptops with security disabled, and we say "hey, here's some code you might like if you want to deploy a security server."
  • oh, no-one pointed out the largest flaw in my plan of renaming 9.1 to Fedora 11, which is that we're in the middle of moving to F10 and F11 feature freeze is in two months. my plan requires that we now move to F11, pretty much immediately.

What happens to deployments?

What OLPC will tell them

Cjb: Mainly what I'm interested in right now is edmcnierney saying that it's okay with him if we tell our deployments "You should run 767, and we might have something better in May, and if not we might have something better in December."

Edmcnierney: What I'm going to be saying is that 8.2.1 is what they should use/upgrade to when we release it, and that we will update the factory to start using that release, and going forward they should look to the next release to be a Sugar-on-Fedora spin for the XO. And that's a combination of software released by Fedora and Sugar Labs, not OLPC.

The future of collecting user feedback

regarding how/where feature requests for 9.1 and from deployments go and get triaged, part of OLPC's job going forward is to collect that input and communicate it to the Fedora / Sugar Labs communities as appropriate. Our value is being a good source for that field input.

Is the eventual goal of direct communication between deployments and sugarlabs/fedora? I think direct communication is fine - no reason to get in the way - but some deployments will find it easier/preferable to talk to OLPC, so we should be responsible for passing on that information. This is an important part of Reuben's job.

The game plan

Rid ourselves of the OLPC monopoly on build signing/dev keys

An obvious thing to do is to help deployments be able to take care of themselves -- have them in charge of dev keys, build signing, build creation, and so on. at this point the deployments can do whatever they want. Mitch Bradley is doing the firmware work to support this.

Push infrastructure out to the community

We'll start pushing infrastructure out to the community. This includes Pootle going to SL, git going to SL, packages going upstream to Fedora instead of in our dropboxes...

Start thinking about planning a release

When I say "planning a release", I mean "getting everything into Fedora in time for their release."

Best proposal of the day

"...we can base [the XO's build] on Debian Potato."

Log

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