--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process
jds2001j-rod: glad you showed up :)
bpeppleFESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, kick_, jds2001, j-rod
Hi everybody; who's around?
* nirik is here.
* jds2001 loves giving folks a hard time
jds2001 here
* Kick__ is here
j-rodfinally made it on time for once
* dgilmore
dwmw2 would like to request Sponsor status
* wwoods lurking while in another meeting
dwmw2I went to sponsor someone and realised I couldn't :)
* notting is here
bpeppledwmw2: we usually send the requests to the list for feedback from the community, but I can't remember if we've done that with FESCo members or not.
dgilmoredwmw2: denied
dwmw2dgilmore: I know where you live
jds2001dwmw2: that surprises me, while we're at sponsor requests, throw my  name in there
jeremybpepple: we have
* nirik nods. We should follow the same procedure for anyone. ;)
jds2001bpepple and I talked about it at OLF, but never made it a formal request I guess :)
dwmw2next week then
* jds2001 nods
bpeppleok, so dwmw2 how about I send your (and I assume jds2001 request) to the list, and we vote on them at the next meeting.
bpeppleok, so let's get started since we got a bunch of items on this week's agenda.
--- bpepple has changed the topic to: FESCo-Meeting - F11/F12 Schedule - https://www.redhat.com/archives/fedora-advisory-board/2008-November/msg00037.html - f13, all
bpepplef13: you want to lead on this?
f13Basically my first mail lays it all out there, and what I'm looking for from fesco is agreement on a target end date for F11, and a less set in stone idea about what to do for F12
f13once those are picked out, or at least the F11 end date, releng (poelstra) can work on a full fledged schedule for F11 with all the internal date points for FESCo approval.
dgilmoref13: so that would give us 6 months for F-11 and 5 months for F-12
f13that is correct
nirikso it's a 1 month shift of or normal, then back on track after f12?
f13I understand there are some concerns about slip potential, and I have some plans for some intra-schedule adjustments to help that
nirik: yes
dgilmorei think im ok with this. the other acceptable option would be splitting the two  and doing middle of may release of F-11
bpepplef13: yeah, that's my only concern about reducing the devel time for f12, since we have less wiggle-room due to the holidays.
jeremyf13: I have very strong concerns about slip potential
dgilmorei do think we need to push F-11 out some
jds2001f13: what intra-schedule adjustments are you comtemplating?
f13jeremy: I know you do, and you've voiced them well on list.
wwoodsdgilmore: you want it to be *longer* than a normal schedule?
dgilmorewwoods: no.
f13jds2001: I'm proposing moving the feature freeze date a week back from the actual beta freeze, to give us a week of integration fixups
dgilmorewwoods: either what f13 is proposing or middle of may F-11 release
jeremyf13: while I appreciate we're putting new things to try to help things which have led to slips in the past, we do that with some frequency.  yet slips are remarkably consistent over the entire life of fedora releases
f13jds2001: I'm also proposing that certain key software packages "feature" freeze even earlier than that, so that they are focused on adjusting for any last minute other feature changes rather than scrambling to finish their features.
jds2001: things like kernel, anaconda, compose tools
jds2001that makes sense, anaconda always kills us for various reasons :)
f13jeremy: that is correct, they are consistant in the amount of about a week, or two total.
pjonesf13: that proposal kindof blows though, since our features are generally dependent on features in other parts of the distro.
jeremyf13: incorrect sir.
nottingjeremy: how so? most of f10's slip is a non-predictive event, of course
pjonesjeremy: what's the standard deviation on our slip time?
jeremythe mean is basically 3 weeks, standard deviation was a week or so
f13pjones: which can be considered on a release by release basis, and I am just proposing, looking for input, I'm not dictating as that would really really blow.
jeremynotting: most of every single slip we've had has been non-predictive
pjonesf13: understood.
jwb_gonei'm here
pjonesf13: all I'm saying is, it has a significant downside.
nottingjeremy: f10 is different.
there may always be broken software or features. there is unlikely to be a 3-week infrastructure blackout again
f13pjones: nod, it's the more contentious proposal too.
jeremynotting: the infrastructure blackout didn't stop work from occurring upstream.  you can't just disregard that time.  if anything, you throw out the data point entirely, but it didn't really make a substantial change to the data
f13pjones: maybe not one that can be enumerated in an ongoing rule, but instead investigated per-release.
pjonesnotting: I wouldn't agree with that.  It's unlikely that it'll be for the same reason, but to me it seems very much like the sort of thing that'll recur on a longer cycle.
jeremythe two largest slips in history were fc6 and fedora 7, each being somewhere between 5 and 6 weeks off from their original schedules
pjonesjeremy: eh, the infrastructure blackout very much did stop work from occurring upstream.
f13it also stopped the work upstream from being consumed in the Fedora downstream
jeremypjones: really?  kernel development stopped?   gnome development stopped?
dwmw2and integrated and tested
dgilmorejeremy: F-7 was largely due to the merge taking so long to complete
jeremyf13: it had some impact, but you can't just presume it was 1:1
f13jeremy: of course not
dgilmorei forget why FC-6 slipped
jeremydgilmore: I can come up with rationalization for every single slip we've had, that's not the point
f13jeremy: wasn't it you though that keeps saying we can't plan for slips?
pjonesjeremy: no, but anaconda slowed severely, and the network-manager changes associated with it did as well.  And those aren't negligible.
jeremyand most of them are unpredictable "thing that had big impact" + then the nominal 1-2 weeks we always seem to get screwed by :/
dgilmorejeremy: sure.  we cant antipipate every thing that will cause need for slipping
jeremyf13: you can't plan for them, but when looking at your future, you have to take htem into your risk analysis
f13jeremy: I think we are.
jeremywe chose may 1st and oct 31st because they both give us the window to get back on track and not run into the holiday time of doom
f13there is risk to sipping F11 to the date that we're proposing anyway, given the amount of stuff that is likely to be poured into it for RHEL
sticksterThe holiday problem is almost entirely on the autumn release, not the May one.
f13there is risk that F12 will suffer, but that's also something we can take into account when setting the schedule for F12
dgilmorestickster: there is memorial day in may
jeremystickster: yes.  but we account for that by trying to pull the spring release back to where it "should" be
jds2001dgilmore: i don't go back to STL for memorial day, for example
dgilmore: but I am for thanksgiving
I think that sort of travel is what we mean by "doom" :)
dgilmorejds2001: sure thanksgiving is the most disruptive outside of Christmas
jeremyf13: the problem is that's then too late...  if f11 is even just the second week of june, then we're to a 4.5 month cycle for f12.  or scheduling it to coincide with the holidays
* dgilmore notes that he will be in .au may 2 - 23
dgilmorejeremy: or slipping until January
nottingjeremy: and i think that lopping an entire month off the schedule is a non-starter. so, you're in essence saying that dates are more important than time-based
f13jeremy: so what is your alternate proposal?
jeremydgilmore: at which point, we're entirely off the may/october bandwagon
f13: I laid out two alternate proposals on the thread. #1) the tuesday close to may 1st as we've always said we'll do #2) if we think that there are _crucial features_ for f11, then let's get their schedules up and set f11 up as a feature based release
dwmw2are there particular reasons for wanting to stick to may/october?
caillonthere are other bandwagons in the lot which are nice, too.  like the august/feb one
dgilmoref13: i kinda like staying with oct 27 but doing may 12 or 19
dwmw2I heard some discussion about wanting to make it _earlier_ than that
jeremynotting: we've done it before.  the 5 month release was only off by a week for f8
j-rodI think the 5 month target would normally be fine and dandy, if not for the huge elephant in the room
jds2001but lopping 6 weeks off is a problem.
j-rod: this proposal is designed to cater to the huge elephant, I thought :)
f13if we can.
sticksterIt's designed to split the difference between catering and ignoring, I think.
jeremycaillon: august/feb kind of sucks, though too.  it puts beta for feb right around the holidays and it means we release right before the desktop release
f13by no means is this a "strong arm" move by Red Hat to try and force the Fedora schedule.
jwb_gonedoes anyone thing it's a bad idea to cater to RHEL6 here?
nottingfedora elephant catering steering committee. it even fits!
bpepplenotting: ;)
wwoodswe have to drop a month *somewhere*
bpepplewwoods: can we drop 2 weeks for f11 & f12?
wwoodsso if we do it in such a way that we can get the full force of RHEL engineering aligned with us and working on Fedora, so much the better
jds2001that's exactly what I was thinking wwoods
nirikwwoods: do we know what that would require?
(ie, which schedule)?
jds2001however, in full disclosure, I'm a RHEL customer too.....so I have a vested interest in RHEL6 being great :)
jds2001and that starts in Fedora, and getting engineering resources aligned with us.
sticksterjds2001: I think everyone who's in Fedora has _some_ vested interest in that
bpeppleok, we've spent about 25 minutes on this, could I get a quick show of hands on f13's proposal to see where we are?
caillonjeremy: true, just saying that may/oct is mostly a historical 6month period.  it was chosen in part because of where we were at the end of a past release cycle.  thought should be given if it still makes sense.
jeremycaillon: a lot of time actually went into getting there.  it was not a fun time :/
* nirik doesn't have a lot of strong feeling on it. Either f13's or stick to our normal dates.
nirikso, I guess +1
notting_sorry, kernel panic. dropped off ater 'bpepple: wwoods: can we drop 2 weeks' ...
dgilmore+1,  though i think id prefer shaving a week or two off of F-11's schedule
jwb_gonebpepple, we have 7.  f13's schedule passed
bpeppleso, I see seven '+1', and one '0' to f13's schedule proposal. so
it's passed.
niriknotting_: that doesn't sound good right before release... hopefully you were using some weird test kernel thats not in rawhide? :)
wwoodsnotting_: i945 random-lockup funtime?
* hadess wonders when we speak about features, because that's why he's here
bpepplef13: is there anything else regarding the schedule we need to look at?
hadess: features are the next item on the agenda.
notting_bpepple: for the record, i'm +1 to f13's proposal, but amenable to splitting the difference if it makes people happy
f13bpepple: not today, we'll come back in a week or so with a full schedule for final approval.
bpepplef13: ok, thanks.
alright, let's move on to features now, unless anyone has anything else to add about the schedule.
moving on.....
--- bpepple has changed the topic to: FESCO-Meeting -- Features -- https://fedoraproject.org/wiki/Features/DeviceKit
mccannjust a drive by comment, but it would be good to keep this in mind: http://live.gnome.org/TwoPointTwentyfive/
bpepplehughsie: ping.
hughsiebpepple: pong
bpepplewhere getting ready to discuss your feature.
hughsieokay, want me to introduce it?
nirikmccann: I think thats one of the reasons we moved to the two dates we have... sync with gnome, possibly other upstream projects.
bpepplehughsie: yup, that would be fine.
hughsiebpepple: well, put bluntly HAL upstream is pretty dead
hughsiethe replacement is a series of daemons called DeviceKit
each one quite specialist to avoid bloat
each one system activated so it only loads when needed
the main one, DeviceKit is a simple wrapper over udev
this allows other daemons such as DeviceKit-power and DeviceKit-Disks to be implemented
DeviceKit-disks is a clever daemon that lets you submit jobs to do things with disks
dwmw2does this help to fix the startup time problems we have with udev?
hughsiefor instance, create raid arrays using a nice GUI tool
dwmw2or is that separate?
jwb_goneso DeviceKit basically does udev<->dbus enablement?
nottingdwmw2: no, not really
hughsiedwmw2: well, it means we only do the coldplugging once, in udev, in parallel
nottingdwmw2: if we can eventually killoff hal, will fix startup times with that
hughsiedoing it in series in HAL means we can take several minutes to start haldaemon on a box with lots of disks
* nirik notes thats a long list of hal using things... I guess the wrapper would mean many of them wouldn't need to change right away.
hughsieDeviceKit-power is a fairl thick wrapper to let the user have accurate time profiling and latency control on all sessions
jds2001i dont think the proposal is to kill hal right now, right?
hughsielatency control alllows us to do agressive power management and not have a sluggish desktop
jds2001just put scaffolding in to allow us to do so in the future?
hal will be arond, although depricated
new development is DeviceKit
jwb_goneso DeviceKit basically does udev<->dbus enablement?
dwmw2so all the packages which currently provide .fdi files will be expected to change?
hughsieso during F10, I'll try to port as much stuff to DK-p as I can
dwmw2admittedly, I have no clue how many that is ;)
* nirik wonders if KDE/Xfce/etc know about this, and are ok with moving to it?
hughsiedwmw2: no, for the moment they can stay -- davidz is working on udev replacment
hughsiedwmw2: a lot of an fdi file you can do in a udev rule, in parallel
so it's much quicker
jwb_gonehughsie, so DeviceKit basically does udev<->dbus enablement?
hughsieKDE can trivially move to DK-p and DK-d as they use SOLID.
jwb_gone: yup, the low level device enumeration
DeviceKit is pretty much feature complete now
jwb_gonehughsie, so why don't you just add dbus hooks to udev?
hughsieit's the -daemons that need the work
jwb_gone: wrong level
jwb_gonewrong level how?
hughsiejwb_gone: udev starts waaaay earlier.
yeah, maybe
bpepple+1 here to DeviceKit feature.
hughsiethe latency bits may be contriversial
jwb_goneas long as i don't even notice it exists, +1
nottingjwb_gone: too late, you know now!
bpeppleok, I see five '+1' to this feature, and no objections, so we have approved it.
jwb_gonenotting, i said noticed, not know
jds2001+1 for the record :)
jwb_goneer, notice
bpeppleThanks, hughsie.
bpeppleanyone, have anything else to add about DeviceKit? Otherwise we can move on to the next feature.
--- bpepple has changed the topic to: FESCO-Meeting -- Features -- https://fedoraproject.org/wiki/Features/VolumeControl
bpepplehadess: ping.
what about it
wwoodsis there a roadmap for converting .fdi files to udev equivalents? documentation to help maintainers move their packages away from libhal?
hughsiewwoods: not yet, davidz still has to talk to kay
dwmw2we'd still have access to the individual mixers, right?
it's always a pain to work out which one does what, on new hardware.
no fscking way we want to trust that to magic
where it works, great
hadessdwmw2: that replaces gnome-volume-control, and uses pulseaudio
dwmw2but don't take away my ability to turn on _every_ bloody mixer on the device and fuck with them till I find a way to make the damn thing actually make noise
nottingdwmw2: iow, work around broken kernel?
hadesswell, you can use alsamixer if you want that
dwmw2pulseaudio is the thing I have to kill to get audio working, right? :)
hadessor KDE
hadessdwmw2: if your setup is that broken, yes
dwmw2does a clean Fedora install on my MBP.count as broken?
nottingis random bugs in one of kernel, alsa, or PA the point of this feature?
bpepplewwoods: are the test plans for the volume control feature sufficient for the qa team?
dwmw2notting: only if we are being denied the ability to work around them :)
wwoodsbpepple: test plans are non-present, although the use case / user-experience stuff is well done
jds2001I'm still unclear on how to actually use the thing.
nirikso this is a new super sound pref app... gnome specific I guess? as long as other things keep working, (pavucontrol, alsamixer) this sounds fine.
jds2001(from a QA perspective, that is)
bpepplewwoods: that's what I was wondering.  I was sure if the use cases were enough for you guys or not.
wwoodsthey're not.
nottingit's not like you can break alsamixer w/o effort
nottingthere's no way this could
jds2001for example: Michael realises that his builtin speakers are too teeny anyway, so wants to only play sound effects at a low volume on them, and keep on playing music through the bigger USB speakers. If the USB speakers were to come unplugged, the sound would go back to the internal speakers. Replugging them would get them their music back.
How do I effect that behavior?
wwoodsI have a clear idea of *why* I want this now, but not how to confirm that the code matches the specification
hadessright now, there's practically no code
* nirik notes after the horror of the openmoko alsa setup, simple sound adjustment sounds like a very good thing to me.
hadessmccann: ?
dwmw2nirik: :)
wwoodsScope gives me a rough outline of the spec
jds2001oh, well that's a good reason not to know how to do it :)
(there being no code)
mccannhadess: oh it's you
hadessmccann: talking about your code now
mccann: volume control stuff
wwoodsbut yeah, it'd be really helpful if the Scope was more detailed about what the expected changes are
bpepplehadess: the feature looks good to me, but I think we need to provide a test plan for the qa folks before approving this feature.
wwoodsthe Test Plan kind of flows from there - if you have a list of changes, writing instructions on testing those changes is usually pretty straightforward
mccannhadess: have you tried it yet?
hadessbpepple: too early for that
hadessmccann: people are discussing it on usability-list as well
bpepplehadess: ok.
mccannyeah i saw that
dgilmorehow will this effect KDE, and XFCE?
nottingit won't
hadessi didn't see your latest code yet
nirikdgilmore: not at all it sounds like.
bpepplealright, so I'm +1 to this feature, but I concerned about approving it without a test plan for QA.
nottingyeah, +1 with the 'need a test plan by feature freeze' caveat
* nirik nods. Or hopefully sooner.
j-rodsure, why not
as long as I can still get at all the knobs via some route, +1
(and/or, everything Just Works)
dgilmoreim 0 for now
hadessfwiw, it will get into gnome 2.26 anyway
dgilmorei think we need to know a test plan,  which include making sure that KDE, XFCE dont have regressions due to the changes
jds2001+1 with a test plan by feature freeze or we drop it.
bpepplenirik, kick_: ?
hadessso it'll get in through upstream
nottingi don't see how kde/xfce/etc can have regressions from gnome adding a panel/notification area applet
nirikyeah, I don't think there would be any...
jds2001actually i'd prefer a test plan by alpha really
dgilmorenotting: so all of the underlying system work is complete?
Kick__+1 from me
nottingdgilmore: according to the page, the PA stuff is
wwoodsjds2001: how about a *spec* by Alpha, test plan by Feature Freeze
jds2001dgilmore: there isn't any, I don't think.....
nirik+1 with test plan as soon as they can... but before feature freeze in any case.
dgilmorenotting: ok.  i was assuming there was low level changes needed
bpepplealright, I see six '+1', and one '0', with the caveat that a test plan is provided before feature freeze.
so, this feature has been approved.
jds2001wwoods: sounds good :)
bpeppleanyone, have anything else to add? otherwise we can move on.
thanks, hadess & mccann.
topic FESCO-Meeting -- Features -- https://fedoraproject.org/wiki/Features/Windows_cross_compiler
rwmjonesgood evening
nottingrwmjones: technically, your two benefits are for fedora the project, not fedora users
bpepplerwmjones: this feature is going to require that all those minGW packages in the queue get reviewed right?
rwmjonesnotting, I think they're for fedora users-who-are-developers, ie. that subset of fedora users
rwmjonesbpepple, yes, there's a mammoth list, 50 or so IIRC
nirikrwmjones: under scope it says you must use your repo... surely those things should be all in the main repo for this feature, right?
rwmjonesnirik, yes, they should be in the main repository
wwoodsthere was a looong argument about that the last time around, wasn't there?
rwmjoneswwoods, that's different
wwoods, we're using a temporary repository for testing right now
* nirik just doesn't think the feature we tout should require/mention another repo.
rwmjonesbut the aim is to get all the libs & dev tools into Fedora
nottingi think we should invite some cygwin people to comment. >:)
rwmjonesthe exceptions are applications which stay outside Fedora, but testers might wish to build them
nottingmore seriously, i agree with nirik
nirikrwmjones: can you modify that to mention that you can test via that repo, but they will all be in for the feature?
rwmjonesnirik, oh maybe it's not very clear, but yes you are right it needs to be clarified
* jds2001 confused
jds2001what's the difference between this and the MinGW feature last time around?
bpepplerwmjones: maybe a link to the mingw packages in the queu or something.
nirikjds2001: this is touting using wine and using the mingw feature from last time.
jds2001is this just getting more libraries in?
rwmjoneshttps://bugzilla.redhat.com/buglist.cgi?quicksearch=mingw32 ... so far .. there are more which I haven't made up RR's for yet
jds2001, well this is hopefully to get a feature into the release notes
nirikrwmjones: also if you could possibly mention which reviews are more important than others? I'd be happy to do some, if you can blast me an email or give me a list of important ones...
jds2001OK, that makes sense.
rwmjonesnirik, from the top downwards
nirikrwmjones: ok. cool.
rwmjonesnirik, basically gcc, w32api & runtime are essential, then follow the remaining libraries downwards as they are roughtly in dependency order
nirikrwmjones: ok.
rwmjonesnirik, but I've been careful to set the bugzilla dependencies correctly :-)
nirikis there any problem using "Windows" here? didn't MS trademark it?
--- bpepple has changed the topic to: FESCO-Meeting -- Features -- https://fedoraproject.org/wiki/Features/Windows_cross_compiler
rwmjonesnirik, well hmmm I hadn't thought about that actually
rwmjonesmaybe spot can comment?
nottingwe'll just have to hit a buzzer every time justin long mentions the feature
bpepple+1 to Window cross compiler feature.
nirikalso, which windows(tm) versions are we talking here? I guess anything wine can emulate?
rwmjonesnirik, yes basically ...
nirikmight note that on the feature page...
+1 here.
rwmjonesanything with the win32 api ... which MS are trying to deprecate because wine've done such a good job of reimplementing it
bpeppleok, I see five '+1', and no objections, so we've approved this feature.
wwoodsIt's a trademark but a) fair use and b) their trademark guidelines specifically allow its use in "a referential phrase such as 'Windows XP'"
rwmjonesok thanks everyone ... if you have questions outside the meeting please email me rjones ... redhat ... com
che_nirik, xp 2000 2003 2008 vista 95 98 2000 nt 3.5 nt 4  win2.0 win3.0 win3.1
bpepplerwmjones: since this feature is dependent on package reviews maybe we can try to schedule some reviews days to get a coordinated effort on it.
nirikche: ok.
Kick__a late +1 from me, I've lost keyboard input  and had to resdtart
rwmjonesbpepple, I would love people to review these packages :-)
nirikbpepple: +1. Good idea.
* jds2001 can throw a hand in too
bpeppleok, anyone have anything else they wish to add before moving on to the next feature?
nirikrwmjones: your bugzilla search picks up some unrelated bugs at the end there. ;)
bpepplealright, moving on.......
--- bpepple has changed the topic to: FESCO-Meeting -- Features -- pushed from F10 to F11 https://fedoraproject.org/wiki/Features/Presto -- everything still relevant?
bpepplelmacken: ping.
lmackenSo, as agreed upon by FESCo a while back, Presto will not be an official F10 feature.  However, we will be trying to roll it out during the F10 timeframe, and announce it as an optional feature.
lmackenIf all goes well, and we get plenty of testing, this should be a solid F11 feature.
chelmacken, thats great.
lmackenI'm going to be working with skvidal and jdieter to streamline the deltarpm generation and integrate it with our updates process.  Seth will be tackling this up from a createrepo angle, and I will be helping with the bodhi integration.
che: indeed
j-rod+1, been looking forward to it for a while
chemaybe it would also be about time to build a 64bit wine
nirikwould rpm switching to the lzma compression affect this any? are we thinking of doing that in F11?
lmackennirik: I haven't the slightest clue.  That's a seth/panu question
* jds2001 didnt know anything about rpm switching compression.
dgilmore+1 to Presto
nirik+1 to presto in any case... just wondering on that
nottingnirik: AIUI, it's more or less a binary diff. if lzma does something odd that makes it less diff-able, it will affect it
bpepplealright, that's seven '+1', and no objections so we've approved this feature for F11.
Kick__why do we decide on it if the maintainers don't think it is a feature ?
jds2001Kick__: it will be a feature for F11
so it is a feature :)
nirikKick__: with what? Presto?
Kick__presto, yes
jds2001we decided to punt to F11 last time around.
Kick__sorry , didn't get it... It is in F10 as a non-feature, but will be a feature in F11
+1, then
bpeppleKick_: yeah, it was a feature preview for F10, since we can't really test it with rawhide.
anyone have any other questions about Presto?
lmacken: thanks!
--- bpepple has changed the topic to: FESCO-Meeting -- Features --https://fedoraproject.org/wiki/Features/Multiseat
bpepplectyler: ping.
dgilmoreKick__: yeah it needs a release cycle of being used for propper testing
ctylerMultiseat refers to having multiple users using one computer, via several sets of monitor/keyboard/pointing device[/speakers]. It can save a lot in terms of hardware, electricity, and admin effort compared to running multiple systems.
* jds2001 notes the test plan is, um, lacking.
ctylerFive years ago, this required major patches to the kernel and to X. By Fedora 8, multiseat systems could be configured by editing the GDM and X configuration files. However, X and GDM changes in F9 made it unusable for multiseat operation. Multiseat users are now facing EOL on F8.
What I'm proposing is making multiseat easy to configure on F11. This involves fixing the regressions in GDM and X (upstream has patches) and either using MDM (multiseat display manager, which is a misnomer as it uses GDM) or extending ConsoleKit to be multiseat aware.
mccannhi ctyler
jds2001ctyler: looks great - how do I test it? :)
* jds2001 notes "get hardware and configure" is not suffcient :)
ctylerTBH, without the hardware, you can't really test multiseat.
* nirik likes the idea a lot, but it's going to be a lot of work it looks like. ;)
jds2001right, say I had the hardware
* jds2001 sees nothing in there about how to configure said hardware
nirikalso notes about what hardware works would be very nice... ie, what video cards live together, etc?
nottingi suppose it depends on what's done in CK/gdm - that would change how it's configured
ctylerIf we go the MDM route -- which I'm favoring -- you will need to configure a backend that matches your setup (multicards, or one card multi output), and fire it up
To this point, i.e., F8, it's all been manual config. MDM or CK could change that for the better.
I think the minimum I'd like to see is to get things fixed back up so manual config works. MDM is an easy next step past that.
ctylerThe patches for the X regressions and removed functionality in GDM are upstream.
nottingctyler: how do you handle X w/evdev?
ajaxpresumably, by extending X to know what seat it's on
mccannwe really should put our efforts into adding device support to CK
ajaxand tagging evdev devices in hal with what seat they belong to
ctyleruntil F9, evdev config in x.org let you match input devices with displays. There's a keyword to turn off the hotplug stuff, but that needs testing.
That would be ideal, yes.
nottingajax: devicekit-input *runs*
niriknotting: InputKit ?
mccannno, ConsoleKit
nirikso, can we approve this as it stands? or should we perhaps see if the test plans and hardware can be updated first?
bpepplewwoods: thoughts?
mccannctyler: see slide 43 of http://www.gnome.org/~mccann/talks/guadec-new-gdm-turns-you-on.pdf
nottingthis feature seems to boil down to 'lock ctyler and mccann into a room to flesh it out'
halflinefwiw, getting multiseat right in consolekit and gdm has been a todo item for a while
bpepplenotting: ;)
wwoodsbpepple: "work with QA to test" is not a test plan
* jds2001 noted the previous two items didn't comprise a test plan either :)
wwoodsscope looks pretty good for a spec, though
jds2001I'm not sure it's really fair that we harp on test plans this early, tbh
but we need to at some point.
at each milestone (alpha, feature freeze) we should come back to it, IMO
bpepplealright, so a common theme on features seems to be that the test plans tend to be a bit on the thin side (if there at all).  What can we do to fix that?
nirikwell, but we don't want to approve now and then realize there was never a test plan.
wwoodsserialize some of the tasks - rather than "you need scope, test plan, etc.. ASAP"
jds2001true as well
wwoodsrequire a fleshed-out scope by Alpha
and then a Test Plan written from that happens between Alpha and Beta (or Feature Freeze)
bpepplewwoods: that sounds good to me.
wwoodswhich means that fesco "approval" needs to happen at each stage
wwoodsbut that's the de-facto procedure anyway
bpepplewwoods: agreed.
* dgilmore really likes the idea of multiseat
nottingmeans we'll be busy
bpepplenotting: yeah.
halflinejust want to reiterate that multiseat has been a concern since consolekit's inception. it needs work, but the work should go there
wwoodsshould mean less confusion at each feature-approval session though
bpeppleDoes anyone object to wwoods proposal?
jds2001but is there any other way to do it, though?
wwoodssince each feature will have distinct phases it must go through
jds2001+1 to wwoods proposal
wwoodsit'd be more obvious whether or not the feature is in the right phase
jds2001having difficulties today notting_ ? :/
bpepple+1 to multiseat feature, based on wwood's proposal.
notting_i love the kernel, it is my friend
Kick__+1 (wwoods proposal)
j-rod+1, ditto bpepple
f13wow, meeting still going!
nirik+1 here too
dgilmoref13: we are planning to make lots of work for F-11
bpeppleok, I see six '+1', and no objections to the multiseat feature, so it's been approved.
wwoodsif we need better guidelines for what constitutes a good Spec (Scope, Blueprint, Roadmap, whatever) I'll be happy to advise
* dgilmore hates having two meetings at once
jds2001f13: that's why we extended the meetings to 2 hours
glad we gave F11 more time to get done (:
bpepplectyler: thanks for your time.
halflinectyler: do find mccann and talk to him
ctylerhalfline: for sure :-)
halflinectyler: so there isn't any overlap in what you two are doing
bpeppleok, that's all poelcat had for us on features this week. so unless there is anything else regarding features we can move on.
--- bpepple has changed the topic to: FESCo-Meeting - https://bugzilla.redhat.com/show_bug.cgi?id=472061 - all
bpepplekick_: you wanted to discuss this.
jds2001i looked into this, everyone knows I'm not a desktop guy
Kick__That's a bug that popped up several times and I think this can get us into trouble
jds2001I just leave stuff in the default config for the most part on my desktop
nirikit's been removed a bunch of times.
jds2001and there's no pr0n in the default config (I use GNOME and Xfce on different machines)
or even potential for it.
Kick__imagine you start the screensaver to lock out your kids, come back and see some porn on the screen
nirikit just grabs images from the net. It doesn't care what they are.
dgilmorejds2001: its random seaches exlicitly have censorship turned off
Kick__jds2001:  you just have to select 'random screensaver' or even wors 'webcollage'
bpeppleKick_: is there anything else we can do, other than patch out the behavior like we have in the past.
notting_so... how did it get added back?
f13I think in the past ti's been worked around by the callers, like the kde screensaver caller
jds2001Kick__: no doubt
f13it wasn't never fixed in the package itself
notting_f13: it was explicitly removed from the list of 'random' screensavers in xscreensaver. not sure if kde/gnome use that
f13and it seems the maintainer doesn't want to fix it in the package?  Not sure here.
dgilmorebpepple: i think that we need to work with upstream add configuration checkboxes to turn on or off filering of results.  defaulting to filtered results
jds2001yeah, this sounds like something more for upstream
Kick__Than Ngo told me that upstream refused the patch we had for this
halflinenotting_: iirc jwz made the source of images configurable
* notting_ rofl
jds2001dgilmore: +1
notting_yeah, we're not going to get jwz to change the upstream defaults
abadger1999f13: It looks like the packager fixed it this time?
dgilmorenotting_: upstream could default to unfiltered
nirikyes, it's fixed by the packager.
nirikthey added a wrapper.
dgilmorenotting_: and we can patch it to the other
f13yeah, I'm not sure the status now with the wrapper
I couldn't tell if it defaults to safe or unsafe
* nirik looks.
notting_realistically - it should not be in the random list, and kde/gnome/etc can just not use it?
Kick__f13:  just start webcollage and see what happens. It took 10secs on my machine to display some X-rated stuff. I'd say the defaults aren't safe at all
nirikok, by default it looks at backgrounds locally (no net), but the orig one is available as webcollege.orig if you want to enable it (disabled by default)
dwmw2how does it find imageS?
dgilmoredwmw2: randmom pulls from nytimes.com altavista.com and ircimages.com
i guess its pulling a page that returns top images queried or some such
niriklook in /usr/libexec/xscreensaver/webcollage it's a perl script.
it pulls from a ton of image sites.
* dgilmore walked in at work in the past and it was up.
dgilmore wasnt happy, and learnt to turn random screensaver off after that
nirikKick__: the fixed one is not in rawhide/F10 final.
I suspect it got re-enabled on a rebase to upstream sometime, as it was off before.
notting_nirik: how recently? was it this way in F9? (note: mtasaka tends to be a push new-release-everywhere person)
nirikDunno... I guess we can look back and try and see...
it was removed in 2004 by than
notting_and 1999
nirikin any case, what do we need fesco to do here? make sure the fix is pushed to all branches, etc?
notting_so, it looks like the behavior in xscreensaver's defaults in F10 is to not use the net
bpeppleok, so we need to verify that this behavior is corrected in all our stable releases, and try to work with upstream on a solution.
notting_but the problem comes with apps that wrap it?
nirikbpepple: there will be no upstream solution.
bpepplenirik: yeah, probably wishful thinking.
halflinewhere upstream == KDE upstream not xscreensaver upstream
nirikwell, kde and gnome shouldn't be using all screensavers, they have a list I thought?
halflinei think if you use xscreensaver this isn't a problem
this is only a problem if you use the xscreensaver screensavers from kde
pretty sure (although not 100%)
jds2001webcollage in any form was not turne don by default when i installed xscreensaver just now
notting_rdieter: how does kde wrap xscreensaver stuff?
jds2001this is on an F9 machine :)
* stickster notes for bpepple, et al., that Docs will not meet today, and yields the balance of its time to FESCo
bpepplestickster: cool, thanks.
stickster(and hopes you don't need it.)
nirikKick__: did you enable that screensaver? what fedora version? what DE?
bpeppleok, so who wants to verify that this is working correctly (not showing questionable material) in our stable branches?
Kick__bpepple:  I'll check that
bpeppleKick_: great, thanks.
anything else to add about this? Or should we move on?
--- bpepple has changed the topic to: FESCo-Meeting - Fedora representative to LSB? - https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00763.html - bpepple
bpeppleOk, Russ offered an invitation to join in the LSB weekly call, and I didn't really see any follow-up on it on the mailing lists.
* nirik has no objection to trying to find someone to do that, but does not step forward to be that person. ;)
bpeppleI sorta agree with him that someone from the new Server SIG would probably be a good candidate.
nirikperhaps we could put out a call for folks interested? or mail provenpackagers or something?
or get someone from packaging?
bpepplenirik: that's what I was wondering also.  I think there's merit on having someone from Fedora being involved in the process.
nirikI think it might be good to at least have someone go and see whats going on and if having a seat at the table is worth it, or if it's a waste of time/effort.
* jds2001 could do that, I guess
bpepplenirik: agreed.  I'll contact the server sig, and see if there interested.  I just wanted to run it past the rest of FESCo before doing that.
jds2001if no one else wants to :)
jds2001bpepple: cool :)
--- bpepple has changed the topic to: FESCo-Meeting - No meeting on 11/26? - all
jds2001fine with me either way
Kick__why ?
notting_yeah, +0 from me
bpeppleOk, next week is a holiday here in the States, and I wasn't sure if we should have a meeting since a lot of folks will probably be traveling.
* dgilmore notes that his baby is due in 2 weeks and could come any day now. when that happens ill not be around a week or two
nirikalso, if we don't slip, thats right after release.
Kick__0, no holiday here
bpeppleso my question is who *won't* be available next week?
* nirik will also be traveling, so +1 to skipping next week.
nirik also invites everyone to join in #fedora and watch the fun of release day/week. ;)
dgilmorebpepple: my availabily is subject to change
bpeppleok, if nirik & possibly dgilmore are the only ones not available we should still have a majority of members here, so I say we plan on having it next week.
everyone alright with that?
* nirik might be able to get on via EVDO, depends on coverage.
bpeppleok, that's everything I had on the agenda.
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
bpeppleanything else folks want to discuss, or should we call it quits for today?
* bpepple notes we've already gone on for 2 hours. yikes.
* nirik is good to close up the meeting now. Tons of things piled up to do
* 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

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