FESCo-2008-08-13

--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process
herloblah blah blah
bpeppleFESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, kick_, jds2001, j-rod
Hi everybody; who's around?
* nirik is here
Kick__ is here
bpepplesadmac2: you about?
* jwb is here
j-rod here
sadmac2yo
nirikI do have to leave for an appointment in about 40min however... so I will have to miss out on the latter part of the meeting.
* jeremy is sitting in the cheap seats
* jds2001 somewhat here
warrenwho is kick?
jds2001$DAYJOB being demanding today
Kick__Karsten
jds2001warren: Karsten
bpepplesadmac2: while we are waiting for the rest of FESCo to show up, do you want to start on you upstart update?
* jwb hands warren a /whois
--- bpepple has changed the topic to: FESCo-Meeting -- Upstart status report - sadmac2
sadmac2Keybuk: are you here as well?
(Upstream is supposed to attend as well)
but anyway
sadmac2So, Upstart 0.5 was just recently released
KeybukI am
sadmac2goot
sadmac2This new release is one we've been blocking on for awhile. There's quite a bit new in it
* dgilmore is here
sadmac2Now we had stated that 0.5 would be when we would begin converting large parts of the system to the "upstart way of doing things"
however, it turns out that the part in quotes has run into some issues
dgilmoresadmac2: why?
sadmac2Keybuk has pointed out, rightly, several very core use cases, pertaining to the mounting of file systems, instance jobs, etc, which are poorly served by current Upstart, and by most enhancements thereto
now, what we have currently could quite well work for many of the later processes
but it has been the opinion of upstream that the event model has begun to show serious weakness
KeybukI wouldn't say the model doesn't work, I'd say the implementation and expression doesn't work ;)
nirikit's quite late in the cycle to be making lots of changes like that isn't it? so this will all need to wait for next cycle?
sadmac2nirik: that's what we're getting at
Its looking like Upstart is going to need to change substantially to solve the problem it was designed for
I'm Ok with this. Even in pure sysv mode Upstart is serving Fedora just fine.
bpepplesadmac2: does this effect some of the other features like 30second startup?
dgilmoresadmac2: nice
sadmac2bpepple: the 30 second startup proposal was made independent of me. you'll have to ask the proposers
bpepplesadmac2: ok.
jds2001sadmac2: will this work be done in time for F11 you think?
Keybuk: ^^
sadmac2jds2001: I tend to overestimate deadlines for safety :) If we can get the new design laid out firmly, I am willing to work full tilt on the code modifications
Keybukjds2001: I don't have any timescales at this point
I doubt work will begin until after LPC
so F12
(since I expect you'd want to land the completed version at the earliest point in your cycle, rather than right before release)
jds2001right
Keybuk0.5.x will be supported for at least the next 18 months anyway :)
sticksterKeybuk: Good point.
bpeppleKeybuk: definitely.
j-rodum, wait, we target stuff that'
bpeppleanyone have any other questions in regard to upstart?
j-rodthat'll be completed just in time all the time
Keybukand to me, it seems better to bed in 0.5 and understand any problems better before rushing off and fixing problems we're only theorising about at this point
j-rodbut whatever. my system boots, and I usually just suspend/resume anyway... :)
nirikI think at this point all we need to say is that we will stick with the current setup for f10, and work can be ongoing to see what the f11/f12 solution is.
bpepplej-rod: same here. ;)
nirik: agreed.
j-rodnirik: yeah, agreement here too
jds2001nirik: +1 here
ion_nirik: Agreed.
bpeppleok, if there is nothing else, we should probably move on since we've got a lot on the schedule for today.
* nirik does appreciate the info tho... would love to have more of this kind of feedback to fesco from other major components... ;)
sadmac2bpepple: I'm done if
sadmac2nobody else has anything
bpepplesadmac2, Keybuk: thanks for the update on upstart.
sadmac2np
bpepplemoving on......
--- bpepple has changed the topic to: FESCo-Meeting -- Revert curl change made for flash - jwb
bpepplejwb or warren want to lead on this?
dgilmorebpepple: i will
warrenspot: you here?
bpeppledgilmore: floors yours.
dgilmoreso spot added a second soname file to curl
to me this seems wrong
drago01no its not
because the api did not change
f13drago01: please let dgilmore finish.
dgilmoreit should be in a compat package if at all
drago01f13: ok
* nirik suggests we put a timelimit on this non issue, so we can get to other business without taking up the entire meeting.
dgilmoreregardless of why it was done it was done in the wrong way
there is 2 issues here
one is that its should have been in a -compat package
the other is that the only user right now is flash
warrenI would say it is clearly unusual, but it is unclear if it is technically wrong.  Both sonames are actually the same ABI, and this is what Debian has been doing for a long time now after they realized that the soname bump was an upstream mistake.  It seems that we have no written guidelines actually forbidding this.
dgilmorewarren: since when have we followed the debian way
warrenThat is an irrelevant question, mentioning of Debian was only to show that others realized the same mistake.
The key question we have to ask ourselves is, is this actually technically wrong and against our guidelines? I would asset that it isn't.
assert*
dgilmoreto me it seems if we do this  then it should be in a compat package
mjg59The issue with providing a compat package in this case is that it's either a new source package (which would be identical to the existing one, except that the soname of the library would be changed) or it'd be a sbupackage of the existing source that provides nothing but a tiny file
* j-rod says put it in a -compat sub-package and move along
mclasenif the abi did not acutally change, why not just patch it to stay with the old soname ?
dgilmoremjg59: there is nothing to say that the -compat cant come out of the same source rpm
mjg59The existing cases where we provide compat packages are when the functionality of the two package versions is incompatibly different.
jwbshould we vote on j-rod's proposal?
jds2001mclasen: lots of stuff built with new soname
nirikmclasen: we already rebuilt everything with the new so
dgilmoremclasen: we have rebuilt everything against the new soname
Kick__-1, I'd rather have a 2k wrapper file in libcurl or a libcurl subpackage then having a 2k compat package or even worse a full compat-libcurl with just the soname change
warrenThe compat sub-package suggestion to me seems just a naive "I don't really care but this seems right." solution, however it doesn't actually change anything, while introduces more inconvenience for a package that quite literally contains a ~2600 byte file.
mjg59dgilmore: Sure, but at that point you have an additional binary package (and associated overhead) for the single purpose of providing something that's effectively a symlink
nirikjwb: if that will make everyone happy, I am all for it.
nirik+1 j-rods proposal of a compat subpackage.
warrenplease wait a moment
j-rodI think a -compat sub-package is the best compromise between the two extremes
dgilmoremjg59: we have always used -compat packages to provide different sonames of the same thing
warrenwhat exactly does a compat subpackage help?
mjg59dgilmore: Yes, because in those cases they provide incompatible ABIs
jwbwait
wait wait wait
mjg59dgilmore: They're two different situations. Treating them differently doesn't create any incompatibility.
drago01what exactly is the problem with the ~2k file in curl? maintaince overhead is ~0 ...
dgilmorewarren: because if i have nothing that requires it i save some space.  useful for resource contrained machines
sadmac2dgilmore: the file is literally empty
dgilmore: well, the lib headers
dgilmore: but its compiled from a blank file
warrendgilmore: 2K file?  Come on.  The extra load it creates on every yum transaction in dep resolution alone is not worth the effort.
dgilmore: that is an incredibly weak argument if that's all you have.
This was seriously making a mountain out of a mole hill.
dgilmorewarren: every 2k adds up.  we need to do much better to be able to create small spins
jeremyfwiw, I think that leaving libcurl.so.3 in the main curl package is entirely reasonable.  we don't require that people split out every single library into a separate package.  the fact that this is different sonames but for the exact same bits doesn't change things
nirikthe only advantage to a compat file is that it makes it more clear to the end user that they are using an old/compat version of something.
spotfwiw, i don't really care at this point, i'll cede to FESCo.
jwblook damnit, issue #2 is where the controversy comes in.  so having some form of technical solution that makes it more acceptable seems like a pretty damn good compromise
jeremydgilmore: having an additional package is going to mean more than a 2k hit almost certainly
dgilmorejeremy: possibly.
warrenjwb: except saving 2K of filesystem space to exclude it is the only benefit?
drago01nirik: they are using the same thing with a different name
jds2001dgilmore: and if you require it, then you're out *more* than 2k
dgilmorejeremy: what do we do when someone accidently does it to something big
drago01nirik: so not really something old and unmaintained
nirikdrago01: right.
jeremydgilmore: what do we do when someone accidentally statically links things?  you file bugs
bpeppleok, we've got a lot of important stuff on the agenda today, and we can't afford to waste a lot of time on this. So I see two proposals basically.
1. Leave it as how spot fixed it.
2. Add a compat sub-package.
j-rod3. yank it entirely
(was proposed on the mailing list)
jwbthat was my mistake
dgilmorej-rod: which is honestly what id prefer.
jwbi retract 3
warrenThere are detriments to #2, while the only benefit is 2k less data if you don't want it.
j-rodwhich is why I figured #2 to be a happy compromise
dgilmoresince the only user AFAIKT is adobe flash
and i honestly dont think we should go out of our way to help them
warrendgilmore: if your actual goal is to disallow proprietary software from our platform, then I'm happy to help implement that.  let's start by ripping out the plugin finder from firefox.
spoti think we'll only be making our userbase suffer.
drago01dgilmore: we don't want to help them but our users
j-rodhonestly, I don't really care that much one direction or the other, I just wanna get to stuff that actually matters to me... :)
mjg59dgilmore: We've already gone out of our way. Doing anything else at this point is arguably going out of our way to spite them.
spotadobe already doesn't care because, "it works on Ubuntu"
jds2001spot: +1
dgilmorewarren: honestly how hard is it for adobe to release a version that links to the new soname?
bpeppleCould I get a show of hands from FESCo member on which proposal they want?
nirikI vote for #1, with the proviso that those who want a compat package should get package guidelines for them approved.
warrendgilmore: it wont work on RHEL4 and RHEL5 in that case, and they are unwilling to QA two binaries.
jwbbpepple, i'm for proposal #2
* jds2001 for proposal 1
dgilmorewarren: thats there problem not ours
warrendgilmore: This is exactly what I mean by extremism is not productive.
j-rodbut it becomes our problem when users (like linus) bitch and moan about no working flash. :)
* dgilmore gives up and lets us walk away from our goals
dgilmoreits the same thing as turning around and saying we will put an old X in so nvidia will work
sadmac2our goals are to spread foss, not to be pointy-headed pains in the asses
drago01dgilmore: our goal was never to _prevent_ people from running closed source stuff
* nirik waits for other fesco votes...
warrendgilmore: Yes, if the old X were the same ABI as the new X but with a different version number.
jwbnirik, you didn't vote
nirikI vote for #1, with the proviso that those who want a compat package should get package guidelines for them approved.
Kick__I'm for proposal 1. This already took way too much of our time, no need to prolong this by having spot repack this
bpepple+1 to proposal #1, just so we can end this.
jds2001dgilmore: i go to local beginner's workshops and stuff all the time. Telling people that Flash won't work in F10, and that I was part of the decision, just doesn't fly with me. That's why I vote for #1
* j-rod abstains from voting
jwbjds2001, i realize this is a complete side issue, but what do you tell them about mp3 playing?
drago01dgilmore: maintaing a compat X would have been a MAJOR pain ... while this one costs us nothing
bpeppleok, I see 3 votes for proposal #1, and 2 for proposal #2, and one abstaining vote.
jwbjds2001, answer that elsewhere.  i'm just curious
warrenNow if someone wants to entertain ripping out the plugin finder, I'm actually in support of that.  Isn't that our last remaining pointer in the distro to proprietary software?
jds2001jwb: it's patent encumberd :/
* dgilmore abstains
jwbwhat?
drago01jwb: mp3
bpeppleok, we've got only a half-hour left, we have to end this discussion for today.
jwbsorry, dgilmore what?
dgilmorejds2001: so is flash,  your arument doesnt fly
j-rodbpepple: I saw 4 for #1 -- jds2001, Kick_, nirik and bpepple
jwbdgilmore, i would really prefer it if you voted
bpepplej-rod: thanks, I missed Kick_'s vote.
dgilmorejwb: if i were forced to it would be #2 of the 2
jwbthanks
bpeppleok, so it looks like we have 4 votes for #1, and 3 votes for #2.
warrendoes fesco need 5 votes to pass, or majority of whoever is in the meeting?
* stickster notes that if this meeting goes over, he'll prevail on Docs to give right-of-way
drago01and one abstain
so 8 people voted
jwbdwmw2_gone didn't vote
warrennotting?
dgilmorewarren: notting is on vacation
warrenwho were the three for #2?
bpeppleI think I counted j-rod in there, when he abstained.
j-rodfwiw, I have a slight personal preference for #2 over #1, if I were forced to not abstain...
* nirik notes he has to leave in about 5min...
dgilmorelet move on and discuss this on the mailing list
jwbagain?
call it as #1 is the winning proposal
dgilmore:( fair enough
bpepplejwb: agreed.
moving on.....
warrenI'm sorry this has been a huge time sink.
--- bpepple has changed the topic to: FESCo-Meeting -- Features -- http://fedoraproject.org/wiki/Features/30SecondStartup
warren30 seconds should be fast? =)
sadmac2this proposal has always seemed a bit vague to me
there's no actual changes suggested in it
* Kick__ wonders if this is still doable without upstarts parallel bootup.
drago01isn't this related to the upstart changes discussed today?
sadmac2Patallel bootup's benefits come into question a lot
mclasenno, this is mostly about harald fixing readahead
j-rodagree w/sadmac2, its rather vague
mclasenbut that got stuck between auditd and the kernel...
nirikyeah, more detail on specific things that will be done to improve time would be nice...
sadmac2earlier ubuntu experiments seem to indicate there's more to reap than the worst-case had suggested, but its not enough data for a theory
nirikthe test plan could use more specifics too... what to install, when to start timing (bios? power on?)
Kick__anyway, the contingency plan covers that. Lets make the bootup as fast as possible, including the modprobe and readahead stuff
mclasenI'd table this until harald's readahead work gets unstuck, maybe ping him about that...
Kick__nirik:  30sec bootchart time, most likely
j-rodback-burner it +1
bpepplemclasen: sounds like a plan. we'll push it to next week's meeting.
sadmac2Kick__: I'd heard talk of modifying bootchart to not stop timing until a firefox instance is successfully launched
bpepplemoving on to the next feature......
--- bpepple has changed the topic to: FESCo-Meeting -- Features -- http://fedoraproject.org/wiki/Features/ApplianceTools
sadmac2so init-to-usable time
jds2001sadmac2: yeah, thats mentioned on the page
bpeppleThis is similar to what rpath provides isn't it?
jds2001yes. pretty similar
Kick__didn't FESCo punt spins to rel-eng ?
jwbyes
huffdNot sure what yall want to hear about/discuss about appliance feature....
bpeppleKick_: yes.
dgilmore+1 to ApplianceTools
jds2001yeah, i questioned that oo
bryan_kearneythis is tools + a spin
jds2001this is more of a toolchain
+1 here
bryan_kearneythe spin is for easy consumption
huffdSO the appliance feature is two things, appliance-tools package, and AOS spin
nirik+1 from me.
bpepple+1 to ApplianceTools.
Kick__+1
* nirik has to go now...
bpepplenirik: later.
j-rod+1
bpeppleok, I see six "+1", so we've approved this feature.
moving on.....
--- bpepple has changed the topic to: FESCo-Meeting -- Features -- http://fedoraproject.org/wiki/Features/ApplicationInstaller
jwbbryan_kearney, please be sure to send the spin part to rel-eng
huffdhuff, ack
bryan_kearneyjwb: will do
jwb: working through the spins group now
jwbk
sadmac2what does this do to us security-wise? is there a new category of vulns that come out of this feature?
dgilmorei have issues with  "Log in with Fedora Account System username and password"
jwbwhy?
jds2001dgilmore: that's just for commenting
dgilmorewe should not require people to have fas accounts to use this feature
sadmac2that does limit usefulness to end users
dgilmorejds2001: doesnt matter
* jds2001 tends to agree
rnorwooddgilmore: FAS account isn't required for the main purpose of installing apps.
jwbso...
jds2001maybe a captcha or something for spam
drago01yeah users should be able to just use it (without any additional barrieres like accounts)
jwbhow does the app verify that it's only installing on a Fedora system?
rnorwooddgilmore: FAS account is required to do things like post reviews, etc.
dgilmorernorwood: plenty more people could provide feedback
warrenrnorwood: one thought
dgilmorethis feature could also be taken up by other distros
rnorwooddgilmore: true.  My view is that it's more valuable if feedback is attributed to a person - and the plan is to expand that from 'FAS' to 'any openid'
warrenrnorwood: have you seen lmacken's CAPTCHA for unauthenticated commenting in bodhi?
dgilmorewith packagekit it should work everywhere
bpepplernorwood: that seems reasonable.
rnorwoodjwb: It doesn't, it requires a browser plugin that owen has written to do the install.
dgilmorernorwood: id prefer the abbility to post feedback without having a user account.
jwbrnorwood, hm ok
rnorwoodAnd my thinking for non-fedora users of this feature is to run a different instance of the webapp (probably sharing data)
dgilmorernorwood: does it tie into packagekit?
warrenrnorwood: have you seen the unauthenticated commenting in bodhi?
rnorwood: might be useful here as well.
rnorwooddgilmore: Yes.  Owen's plugin calls packagekit's API
rnorwoodwarren: I don't have a religious aversion to unauthenticated comments
bpepple+1 to this feature.
dgilmorernorwood: so its definatly possible that it could find its way into other distros.  even using our frontend
jwbi'm just wondering if people are easily going to be able to use this with an OpenSuSE system (for example) and have distaster
but that seems overly paranoid
rnorwooddgilmore: well, for instance, one issue is that package names are not consistent across distros.
dgilmorernorwood: sure
jwb+1 from me.  seems neat
mclasenmost of the feedback here should probably go on the discussion tab of the feature...
rnorwoodjwb: no, because all it does is say 'install package by name'
bpepplemclasen: agreed.
drago01dgilmore: well nothing prevents other distros to point to our repos
j-rod+1 here
dgilmoreother than the fas requirement seems good to me
Kick__+1
rnorwoodmclasen: agreed here too - or on mailing list
jds2001+1 here
bpeppleok, I see five "+1", so we've approved this feature.
anyone have anything else to add before moving on?
--- bpepple has changed the topic to: FESCo-Meeting -- Features -- http://fedoraproject.org/wiki/Features/Eclipse34
rnorwoodbpepple: just a quick note that the only things for this landing on the ISO will be owen's plugin and a desktop file to put it in the app menu
bpepplernorwood: thanks for the clarification.
jwbthe strikeout in this page is awesome
j-rodis an updated eclipse really feature-worthy?
jwbyes?
jwbfor publicity reasons
j-rodI mean, I'm fine with publicizing updated packages, but do we really need to vote on them as new features?
I don't see a feature page for shipping a 2.6.27 kernel anyway
dgilmoreit would be nice if there was some idea in the feature  what new features upstream has added
j-rod(of course, I haven't actually looked...)
sadmac2j-rod: eclipse is a huuuuuuge deal for a lot of people
jwbmajor upgrades should be tracked via Feature so rel-eng/qa can see the fallback options are in case things are broken
j-rodand eclipse isn't even installed on lots of systems
jwbj-rod, dude... the kernel just isn't that glamorous anymore ;)
j-rodheh
bpepple+1 to this feature. I pretty much agree w/ jwb & sadmac2.
drago01j-rod: we always update kernels during the lifetime of a release so its not worth it
jwb+1
jds2001for sure this merits a release note since there's breakage
j-roddrago01: we always update lots of packages...
oh, sorry, didn't read all of that
Kick__+1 from me
jds2001+1
\
dgilmore+1 (with the caveat,  what new features are in it to advertise)
jds2001needs some work on the test plan, though....
j-rod+1
bpeppledgilmore: could you add that to the discussion page?
dgilmoreit would be nice to say new eclipse with foo abd bar
rather than new eclipse
bpeppleok, I see five '+1', so we've approved this feature.
j-rodbut I'm writing a feature page for upgrading dvgrab from 3.1 to 3.2.
bpepplej-rod: ;)
--- bpepple has changed the topic to: FESCo-Meeting -- Features -- http://fedoraproject.org/wiki/Features/FirstAidKit
poelcatj-rod: why are you so down on features? :)
drago01j-rod: new features the kernel provides are in seperate pages (we had tickless, now webcam ...)
j-rodheh
sadmac2j-rod: you're complaining that we call all new packages features? there are places where they call all their bugs features.
j-rodI'm not down on features, just the idea that we need to approve the eclipse people shipping the latest upstream release
that's already what fedora is
its expected
we can tout that without having to rubber-stamp it
jwbside issue
dgilmorebpepple: discussion started
bpeppledgilmore: thanks.
j-rodsorry. :)
* j-rod shuts up now
bpeppleok, the FirstAidKit looks pretty cool.
sadmac2I like this a lot. I think the "oh crap, it broke" use case has been neglected, and with the ammount of dated/disinformational "make your graphics work" howtos on the internet, new users break fedora a lot.
j-rodnow *this* is a new feature. :)
+1
jeremyhaving it publicized a bit could also be a big win for getting more people contributing plugins (the things which actually help fix your system)
bpepple+1 here also.
Kick__+1 for FirstAidKit, I like that feature and the plugin capabilities
dgilmoredo we have any idea what plugins currently exist
jds2001+1
dgilmoreis there an easy framework for writing new ones?
i dont see either of them covered
jwb+1
sadmac2dgilmore: https://fedorahosted.org/firstaidkit/
jeremydgilmore: root password, xorg reconfig, and something with mdadm are plugins that are written.  framework for writing new ones exists, is documented, and is going to be the subject of one of the fudcon presentations
sadmac2dgilmore: near the bottom of that page
bpeppleok, that's five '+1' to this feature.  It's been approved.
f13dgilmore: there was some good pages written up for creating plugins, we tried to get people doing plugins at FUDCon
dgilmorejeremy: ok we should be very clear of the limitations when we advertise this
quaidf
dgilmorewe dont want people thinking it will do everything
bpepplestickster: you mind if we go 10 minutes late?  I'd like to finish one or two more features.
dgilmorewe its only a small and growing subset
jds2001dgilmore: https://fedorahosted.org/firstaidkit/wiki/FirstaidkitPluginDoc
zodbot<http://tinyurl.com/5zaxmf> (at fedorahosted.org)
quaidbpepple: roll with it
bpeppleok, moving on then.....
https://fedoraproject.org/wiki/Features/GNOME2_24
quaidDocs :: we'll start in #fedora-docs, then move here
jwb+1
dgilmore+1   ill add to the discussion page that we should clearly state what is covered  and here is where you can add coverage
Kick__gnome2.24 is only 40% done ? Is there enough time to get this ready for inclusion ?
bpepple+1 though I have some comments to add about telepathy on the discussion page.
quaid: thanks.
sticksterbpepple: go right ahead
sticksterAh, I'm late as usual.
mclasenKick__: gnome 2.24 is already 73% done...
Kick__ok, the page needs an update then
mclasenyeah
Kick__+1 in that case
bpepplejds2001, j-rod: you have an opinion on this feature?
j-rod+1
jds2001+1 here.  A complete GNOME test plan would be great, though, as well as mention of what the "notable new features" are :)
sadmac2jds2001: I'd imagine a couple of links to fd.o could take care of most of that
bpeppleok, that's six '+1' to this feature, so we've approved it.
j-rodalthough again, I already assume every fedora release is going to be carrying the latest gnome release
mclasenjds2001: a "complete gnome test plan" is a pretty ambitious undertaking...
--- bpepple has changed the topic to: FESCo-Meeting -- Features -- http://fedoraproject.org/wiki/Features/PythonNSS
jds2001mclasen: i know :)
bpeppleThis is one we voted against last week, but the owner gave us additional info about it being written inhouse.
jds2001that's why it's a nice-to-have..
dgilmorethe python openssl bindings are really bad
j-rod+1 for python-nss this round...
bpepple+1 here also.
jds2001imo, it then becomes something that differentiates Fedora, so +1 here
dgilmore+!
Kick__no idea on that one
bpepplejwb: you have an opinion?
jwbsorry, reading
bpepplejwb: np.
jwb+1
bpepplealright, that gives us five '+1', so this feature has been approved this round.
jds2001does warrant release notes, though.
jwbyes
bpeppleok, let's do one more feature, and then wrap it up for this week.
--- bpepple has changed the topic to: FESCo-Meeting -- Features -- https://fedoraproject.org/wiki/Features/Sugar
j-rodwould also like to see some notes on plans to convert existing stuff to use python-nss
probably an f11 feature though
bpepplej-rod: yeah, that not a bad idea.  I'll add something to the discussion page.
sadmac2how would sugar's presence look in fedora? would it be an option alongside gnome/kde/xfce in anaconda?
jds2001you're throwing me off bpepple  :)
sadmac2also 5% ?!
* jds2001 had FF tabs open in the right order :)
gregdeksadmac2: Probably more like 50%, really.  An awful lot of sugar is already packaged.
rnorwoodsadmac2: Yes, as another option in GDM, if you have it installed
sadmac2cool
rnorwoodsadmac2: apologies for the low % complete - gregdek's fault.
sadmac2heh
bpepplejds2001: yeah, I tried to grab a couple of features I thought wouldn't have prolonged discussions since we're short on time.
gregdekrnorwood: Bite my shiny metal ass.
bpepple+1 to Sugar.
j-rod+1
Kick__+1
jds2001+1
jwb+1 only if it comes with the background set to a picture of gregdek's shiny metal ass
dgilmore+1
* jeremy refuses to add pictures of gregdek's shiny metal ass to the distro
jeremy:)
bpeppleok, that's six '+1', so we've approved Sugar as a feature.
rnorwoodjeremy: it would be a win over ubuntu.
* gregdek is buffing.
dgilmorejeremy: i have upshort pictures of kernel hackers can we add those?
gregdeklolol
sadmac2rnorwood: yes, but at what cost?
gregdekNo.
bpeppleok, we've used enough of the doc groups time, so let's end this meeting.
* bpepple will end the meeting in 60
bpepple will end the meeting in 30
bpepple will end the meeting in 15
bpepple-- MARK -- Meeting End
Thanks, everyone!

Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!