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