--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
Hi everybody; who's around?
* tibbs here
spot is here
nirik is here
f13I'm somewhat distracted, trying to stem the tide of spam
fraggle_ f13 finnzi fab
bpeppleok, I see seven of us here, so we can probably get started.
dwmw2_n770I need to head home shortly
--- bpepple has changed the topic to: FESCO-Meeting -- Secondary Arches Releases and FESCo's role over them -- all
bpepplef13: you want to lead this one?
f13well, I just thought it was a bit odd that there was an announcement of a secondary arch release, and I don't recall it being mentioned at FESCo at all leading up to the release announcement.
I'm perfectly content letting the secondary arch SIG run things, but letting FESCo know there was a release coming might have been nice
nirikwas that a full release? or just a alpha/testing one?
dwmw2_n770and didn't it have packages not in f9-updates?
f13= Release notes for F9-beta on ia64 =
dwmw2_n770: yeah, I think the fedora-release was in updates-testing
nottingit's a final release, the relnotes were not updated right (so it was said)
dwmw2_n770updates-testing isn't so bad
spotdwmw2_gone: all of their changes were committed to f9 cvs
(at least, to the best of my knowledge)
f13comitted != built though
dwmw2_n770still not so bad
nirikso what do we suggest here? ask secondary arches to ping Fesco before release? or talk to rel-eng ? or ?
spotf13: does rel-eng want to coordinate the secondary releases?
dwmw2_n770talk to fesco I think
f13talking to FESCO is fine with me
dwmw2_n770rel-eng is reasonably represented on fesp
spotokay, sounds fine to me
nirikok, and what does fesco do? say "yes, please announce your release" ? or do we check anything on it?
dwmw2_n770a brief sanity check makes sense
* jwb is here now
bpepplealright, anything else on secondary arches or should we move on?
ok, moving on..........
--- bpepple has changed the topic to: FESCo-Meeting -- Application approvals for cvsadmin - f13
f13I just simply wanted to get a vote from fesco on handling approvals for people getting cvsadmin access, since such access means complete access to all packages / control files in cvs
* warren here
f13it was mentioned on list that allowing current admins of that group be the body that approves new members, however they see fit
warrenthat seems like a good idea
nottingf13: +1 to that, fesco can revoke if necessary
spotseems fine
bpepplef13: +1
f13+1 from me.
jwbhow do we handle promotion of new admins of that group?
dwmw2_n770seems reasonable... cancelledyou include me?
tibbsPredictive text input FTW.
f13jwb: same group of people IMHO
nirikyeah, +1 from here... FESCo reserves the right to revoke/promote if need be (in its oversight capacity)...
tibbs+1, I suppose.
dwmw2_n770 +1
f13dwmw2_n770: I don't necessarily want 'cvsadmin' to just be a method to bypass cvsextras settings.  It's more for administrative type tasks.
dwmw2_n770: but that's my opinion.
bpeppleok, I see seven '+1', so we've approved allowing current admins of that group be the body that approves new member.
f13(just like secondary arch rights aren't there to allow them to fiddle with things that aren't secondary arch related)
bpeppleanyone have anything else to add? otherwise we can move on.
* nirik wonders who was wanting in cvsadmin that started this discussion...but I guess it doesn't matter.
dgilmore is here
tibbsnirik: I believe it is lmacken.
jwbwhat?!  NOOO
can't trust that lmacken dude...
* jwb kids
bpeppleok, onto features....
--- bpepple has changed the topic to: FESCo-Meeting -- Features -- https://fedoraproject.org/wiki/Features/GoodHaskellSupport - poelcat
bpepplepoelcat about?
poelcatvote away :)
bpepple+1, though I wonder if it truly is a feature or not.
notting"Many developers, scientists, and other technically oriented people are drawn away from Fedora for a lack of Haskell support. "
[citation needed]
* nirik notes several of the packages (like darcs) are already in and usable...have been for a while.
dwmw2_n770 has to head home
tibbsFPC will hopefully discuss the guidelines on Tuesday.
notting+1, i suppose. not sure it's feature-worthy
tibbsWell, they'd like to tout it in the haskell community.
jwbthere is nothing that makes it clearly not feature worthy
jwbso publicity about it is fine
tibbsErm, +1
bpeppleok, I see nine '+1', so we've approved this feature.
--- bpepple has changed the topic to: FESCo-Meeting -- Features -- https://fedoraproject.org/wiki/Features/Fingerprint - poelcat
bpeppleThis was one that was pushed backed from F9 wasn't it?
spoti think so
tibbsIt's still going to block on libusb.
spoti'm ok giving it the goahead, if it doesn't make it, we're in no worse state.
dwmw2_n770thinkfinger works quite nicely in f9
dwmw2_n770what's new?
tibbsThis doesn't seem to involve thinkfinger at all.
spotdwmw2_gone: did you read this? thinkfinger is dead, this is better integration
bpeppledwmw2_n770: I believe this is new: https://fedoraproject.org/wiki/Features/Fingerprint#Detailed_Description
f13well, I"d like to see it get in too, so +1
wwoodshey, that's a pretty good (if minimal) test plan
tibbs+1 but I guess most of this hinges on whether jnovy can update libusb.
bpeppleok, I see eight '+1', so we've approved the fingerprint feature.
--- bpepple has changed the topic to: FESCo-Meeting -- Features -- https://fedoraproject.org/wiki/Features/DeviceKit - poelcat
bpeppleThis looks pretty cool.
f13+1 from me
although I disagree that release notes aren't necessary
tibbsYes, this looks neat.
f13it might be necessary to make sure existing release notes don't have directions that would benefit from actually having DeviceKit to use
wwoodsTest plan needs a *lot* of fleshing out, but it's not in rawhide yet, so that's not critical
tibbsI note that currently it's set up to block on the KDE stuff being ported.
f13tibbs: yeah, that's something to pay close attention to
* nirik wonders how if at all it will work under Xfce/others...
spotwill this integrate with anaconda?
f13spot: there is talk of that yes
dgilmoreits light on detail,  but otherwise it looks ok
spoti would hate for it to look significantly different
f13<jeremy> fyi -- we might be "lucky" enough to get to switch our disk probing to use devicekit instead of hal for f10.  davidz was typically cagey about what would remain and when things would land :-/
dgilmorenirik: there is mention of KDE but thats it
f13 Dependencies
spotf13: it would be nice to see anaconda integration as an item
f13Solid's (KDE's) disk management also needs to be ported to DeviceKit-disks.
tibbsI read through the mailing list thread and the explanations seem to make sense.
jlaskait notes it's a partial replacement for hal ... it would seem worthwhile identifying which pieces it's taking over (from a testing perspective)
tibbsBut I wonder how much of our system links into the HAL stuff that we don't really know about.
nirik: Do you know the extent that xfce plays with hal?
wwoodsjlaska: yeah, we'd want to expand the test plan to include other stuff that uses (used) HAL's disk support
tibbs"Components which depend directly on the disk functionality in hal, such as gvfs and Solid, have to be ported to DeviceKit-disks."
* jlaska runs `rpm -q --whatrequires hal`
niriktibbs: thunar-volman uses it to find removables, etc.
so there would need to be changes there probibly.
tibbsThen it may be worth getting clarification on that, and the porting of that added to the "Dependencies" section.
* f13 notes that these are all wonderful questions for the discussion tab
bpepplef13: agreed, we need to add them there.
nottingthere's a certain point at which things are pushed to the upstream of said technologies
niriksure, can add some to the discussion tab.
tibbsWell, sure, but we're kind of in a meeting to vote on it now.
spoti'm not opposed to this feature, it sounds great... but given how intrusive it will be, i'd like to see a lot more details on porting other components
nottingfor example, if openssl changes api/abi , it's not necessarily up to the openssl maintainer to port everything
spotnotting: no, but it sure is nice when they describe how to port.
wwoodsdetails on porting, hints on finding things that will need updates
jlaska... yeah, applications that must be changed to use DeviceKit by F10
f13pointers to documentation
tibbsI guess it would be at least nice to know if it's just the matter of calling different function names and listening for different dbus messages or whether there's a complete logic rewrite required.
jlaskamaybe a DeviceKit-hal layer is used to map the old methods to the new?  dunno if possible </crack>
tibbsSo I think we're at three +1's at the moment.
jlaskaI think we'd want some of these questions answered before we fully take it, no?
spoti'm not comfortable voting +1 without some of these items addressed
tibbsCan we provide a list of requests for additional info?  What do you want to see?
spotdetails on anaconda integration
spotlist of packages affected by the change
bpepplespot: I'm fine with that.  How about the people with questions they want answered add them to the discussion page.
f13I'm really curious if they'd roll it back if the KDE part isn't done in time
tibbs"Please provide links to documentation and porting information"?
dgilmorespot: agreed
* nirik added a thunar-volman question to the discussion tab...
f13I added my question too
spotmine as well
bpeppleok, let's move on to the next feature then.
tibbsFYI, http://hal.freedesktop.org/docs/DeviceKit/
tibbsBTW, the use of gobject seems controversial according to the list traffic.
* nirik thinks we really need KitKit to keep track of all the Kits. ;)
bpepplenirik: ;)
bpeppleok, onto the last feature for today.
--- bpepple has changed the topic to: FESCo-Meeting -- Features -- https://fedoraproject.org/wiki/Features/Bluetooth - poelcat
tibbsHas this changed at all recently?
It doesn't look like it's changed since we discussed the feature during F9.
bpeppletibbs: I believe the documentation section tells the changes from previous release.
nirikyeah, it's not clear what things are going into f10, or are already in or what
tibbsAnd I note the word "test" doesn't seem to appear at all.
jlaskaexcessive use of the words "possible solutions"
spotaside from adding a release notes section, nothing has changed since it was imported into the new wiki
nottingwell, i suppose the issue is that this is more of a 'todo' list
tibbs"the CUPS backend work is available in Fedora 8 and rawhide."
nottingand there's not a good view of which are still todo, and which aren't
wwoodsyeah a lot of the stuff in there has landed in previous releases
f13does hadess know it's being pitched as an F10 feature again?
poelcatf13: yes, though admitedly I should have done a better job reviewing it
mclasenhe's at guadec right now, I can ask him when he comes back
tibbs"Rawhide's nautilus uses GVFS, support will be in gvfs 0.1.9.", but F9 has gvfs 0.2.5 now.
f13yah, this probably needs a good overhaul for what's current and not, with a clear idea of what we're looking to be "featured" in F10
poelcattypically he puts a bunch of stuff on that page and then forks it at release time to reflect what was accomplished during that release cycle
* bpepple thinks we need to check w/ hadess before voting on this.
spotpoelcat: is RPM4.6 not ready? i want Panu to have as much time as possible for this to hit
not that he should feel held up by it, but still
poelcatspot: the feature page?
spotpoelcat: yessir
* poelcat hasn't done a full scour since tues
wwoodshttps://fedoraproject.org/wiki/Features/RPM4.6 looks pretty ready
spotokay. thats the one i'm most excited about. :)
* spot bounces
f13 reads
poelcatbpepple: if there is still time go for it
bpepplepoelcat: we've got time.
--- bpepple has changed the topic to: FESCo-Meeting -- Features -- https://fedoraproject.org/wiki/Features/RPM4.6 - poelcat
* bpepple goes to read it.
spot+1 from me as well (duh)
spotFPC will tackle the changes for F10+ if this feature makes it in
wwoodsneed to flesh out that test plan to have some specific test cases that people can run
f13I give this +1, I"ll be closely watching the buildsystem when this goes in
wwoodsbecause we will need serious buy in from everyone everywhere to shake out all the bugs
f13I'm also curious if we (fesco/whomever) wants to schedule a full rebuild of the distro against hte new rpm
f13and whether we wnat to default to lzma compression for F10
* poelcat notes that feature pages like RPM4.6 are a feature wrangler's dream
bpepplef13: Aren't we going a rebuild for gcc this release also?
nottingf13: full rebuild or a test rebuild?
nirik+1 here
f13bpepple: hand wavy.
wwoodsother than that, if my vote counted it'd be +1
dgilmoref13: we need 2 rebuilds to take full advantage from what Panu said
f13notting: a test rebuild will be done by mdomsch.  I'm talking about a full rebuild, to enable things like lzma
nirikperhaps mdomsch could do a run with the new rpm?
f13dgilmore: yeah.
nirikalso, how does this affect deltarpms?
nottingf13: i'd be curious as to the size savings. doesn't help livecd, and the non-live spins aren't *that* bad
spotlzma would be great to enable if possible
dgilmoref13: if we accept this then we should schedule the 2 full rebuilds
spotnotting: it would make yum transactions a bit quicker
dgilmorenotting: it would save disk space on mirrors
f13notting: we can test rebuilds on the side with lzma settings to see
drago01"To enable support for LZMA package payloads, a new version of lzma-libraries will be needed, but this is out of scope for initial introduction, more of F11 material. "
f13dgilmore: the feature doesn't mention doing the rebuild.
dgilmoref13: we probbaly should get it added
* spot is also ok with this hitting in F11
nottingspot: downloads, not the transactions themselves?
f13however, since RHEL has to rebuild our packages, it'd probably be valueable to them if we've done a rebuild with this rpm to shake out any issues.
spotnotting: yeah, thats what i meant
f13I'm with spot, I'd be ok with pushing the full rebuild for this rpm to f11 timeframe
nottingooh, actually a memory/uncompress cpu vs zlib/bzip2 would be nice
f13leaving the f10 timeframe to get rpm right, so we don't mass rebuild more than we have to.
* spot idly wonders if lzma is parallelized
tibbsspot: It is.
spottibbs: very nice.
* nirik is ok with rel-eng figuring out when and what mass rebuilds we need and letting fesco know.
spotnirik: +1
bpeppleok, I see six '+1' for this feature, anyone else want to weigh-in?
bpeppleok, that's seven '+1' (and one from our QA guy), so this feature has been approved.
do we also have to make a decision about the rebuild now also?
spotbpepple: i'm ok with letting rel-eng decide that
tibbsDo we know when the new gcc is supposed to hit?
bpepplespot: I'm fine with that also.  f13 that good with you?
nirikif we do a mass rebuild for rpm, then it's a full one right? even noarch, etc...
dgilmorenirik: yes everything
bpepplepoelcat: anything else on features we need to discuss today?
poelcatbpepple: that is all except to note that I think the presentation and discussion of the rpm feature is fine example
bpepplepoelcat: duly noted.
poelcatthat this process is not that hard :)
f13yeah, +1 from me.
bpeppleok, moving on since we're at the top of the hour.
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
bpeppleanything folks want to discuss before wrapping up for today?
spotI have a few items related to F10 I want to mention
f13Schedule approval
bpepplespot: floors your.
tibbsPlease note that I will be on vacation from July 16 until Aug 6, and will probably miss several meetings.
spot1. I'm going to purge anything under the Artistic 1.0 license only from Fedora before the Alpha.
* notting will be out 8/4-8/18
spoti've spent more than a year trying to get everything I could relicensed with the upstreams
nottingspot: how many things will that affect dependency wise?
spotnotting: i will send an email out before i do it which details that.
nottingspot: have you done the check briefly? are we talking 10 things, or 500 things?
f13spot: make it a feature 9:
spotnotting: rough count around 40, mostly perl modules
dgilmorespot: does it mean half of perl goes?
spotf13: i can make it a feature, but its legal driven
(which is why i didn't do it)
dgilmorespot: i think its a good feature.  it shows we take licensing seriously
spotokay, i will write it up as a feature
tibbsTest plan: Look at the repo and verify that the packages are not there.
metherspot: does Debian accept the license as free?
bpeppletibbs: ;)
spotmether: no.
f13spot: yeah, but making it a feature provides a good place to coordinate changes, show completion status, etc..
it doesn't have to be an advertised feature by us.
a rollback plan
spotMy 2. item was around packages putting files in /srv
FPC voted not to permit this, so I was going to work with the maintainers to get this resolved before F10
(FESCo ratified as well)
dgilmorespot: is there many putting stuff in /srv?
spotits only a handful of packages, but i wanted it on the record. :)
dgilmore:)   ok
bpepplespot: seems reasonable.
f13spot: yay!
spotthats all from me
(for now...)
bpepplef13: you wanted to discuss the schedule?
thanks, spot!
f13yeah, I don't remember if we (FESCo) had actually approved the F10 schedule
bpepplef13: I don't think we have.
f13releng did, although on Monday we adjusted it slightly to take OLS into account (pushed alpha out a week)
so we wanted to alert FESCo to this, as well asn make sure FESCo had approved the schedule in the first place.
I wasn't sure if that was fully delegated to releng or not
http://poelstra.fedorapeople.org/schedules/f-10/f-10-all-tasks.html fwiw
notting+1 from me
bpepple+1, but truthfully, I'm fine w/ delegating it to rel-eng.
nirik+1 here.
f13+1 from me obviously
bpepplespot, jwb, dwmw2_gone, dgilmore: ?
* Southern_Gentlem looks at clock
bpeppleSouthern_Gentlem: yeah, we're running late.  One second, and I'll start to wrap thing up.
bpepplewell, I only see six votes for the schedule, but we need to wrap things up.
please somebody approve the schedule (:
bpepplewarren: ?
f13jwb voted for it in the releng meeting, we could assume a +1 here
as did warren IIRC
bpepplef13: that works for me.
FESCo has approved the schedule.
f13(mayhap we have too many relengy people in fesco...)
nottingquick, let's slip it!
bpeppleok, let's put a fork in 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!