bpepple+FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, kick_, jds2001, j-rod
bpepple+Hi everybody; who's around?
* nirik is here.
* jds2001 none
notting+co-meeting, but here
Kick_+I'm here
* jwb is here
bpepple+ok, I see seven of us, so we can probably get started.
--- bpepple changed topic: FESCo-Meeting -- Feature not at 100% by Freeze - https://fedoraproject.org/wiki/Features/EFI - all
bpepple+poelcat: you about?
wwoods+we have another meeting - not sure if we're going for synergy with FESCo or if that's a collision
wwoods+oh god I used synergy without irony
bpepple+wwoods: should be ok, we don't really have much on our agenda today.
dwmw2+yay, vpn client running as non-root under NetworkManager
bpepple+ok, looks like poelcat isn't here/
jwb+is pjones ?
* nirik is asking pjones to join us
bpepple+According to Features process, features that aren't completed by the freeze dates should be dropped.
bpepple+pjones: is the efi feature done, and the wiki just not up to date?
poelcat+bpepple: i'm told it is 100%, but have a hard time getting full update to 100%
pjones+well, it's really a large number of small things.  but the wiki page is basically accurate.
jwb+we can, technically, drop the ia64 stuff right?
jwb+as in, not include it in the status
pjones+that would make the page less useful
pjones+so, you know, it kindof defies the point.
jwb+i don't mean remove it from the page
dwmw2+but disregard for the purpose of considering whether we should revert
jwb+what he said
dwmw2+although would we _really_ revert anything?
pjones+no, we really wouldn't.
jwb+"revert" in this case would be "don't pimp it as a Feature"
dwmw2+the only thing we'd revert would be the switch on ia64 from elilo to grub.
dwmw2+anything else is just new stuff
nirik+just not trumpet it as a feature.
jds2001+just becomes a marketing thing at that point.
pjones+(I don't really care if we trumpet it or not...)
* dgilmore is here
pjones+(note that it is not currently in the F10 category)
bpepple+So, it sounds like we should drop it for F10, and push it to F11 (where we'll do the trumpeting). Any one disagree with that?
nirik++1 from me
Kick_+sounds ok, +1
j-rod++1 worksforme
jds2001+are we reverting the ia64 change?
dwmw2++1, understanding that 'drop' just means no marketing
dwmw2+jds2001: no, we never got as far as making it
jds2001+oh, ok then :)
bpepple+dwmw2: correct. no marketing.
dgilmore+pjones: so grub works on intel macs?
dgilmore+but not ia64?
dwmw2+grub works on intel macs.
dwmw2+X crashes (for me, at least)
dwmw2+could use xfbdev, I suppose.
pjones+also some other !ia64 intel machines.
dgilmore+so anaconda uses grub on intel macs and elilo on other efi machines
pjones+it still uses elilo on ia64.  On all other efi machines, it uses grub.
bpepple+any other questions in regard to the efi feature? Or should we move on?
dgilmore+move on
--- bpepple changed topic: FESCo meeting -- Elections
bpepple+fiy, I talked to stickster and he wants us (Board & FESCo) to hold our election on Dec. 7-20.
bpepple+I told him we didn't have a problem with that.
stickstersorry to poke head in -- fwiw, Matt Domsch kindly put the proposal on FAB for those dates
sticksterinput welcome!
jwb+that's fine
bpepple+d'oh, kicked myself from the channel.
jds2001+sounds good to me, gotta start the re-election campaign :)
bpepple+In case stickster didn't mention mdomsch was looking at starting the nomination period this week with it ending on Dec. 3.
bpepple+anyone have any questions about the election? Otherwise we can move on.
jwb+he did.  we're all good with it
nirik+how many seats are up?
bpepple+nirik: 4.
bpepple+anything else?
--- bpepple changed topic: FESCo meeting -- Free discussion around Fedora
bpepple+ok, that was everything I had on the agenda.  Anyone have anything else they would like to bring up?
j-rod+so jds2001 and I (and some others) briefly tossed around thoughts about comps...
jwb+bpepple, who is up?
ubertibbs+Did dbhole contact anyone about the liveconnect stuff?
bpepple+jwb: If I remember correctly it's: j-rod, Kick_, jds2001, and yourself seats up for election this round.
ubertibbs+He was asking if it was too late to add a feature and was told that it was, but he still wanted to get it publicized.
ubertibbs+It's a pretty big deal.
bpepple+ubertibbs: I agree, it's a pretty cool feature which we should be trumpeting.
jds2001+what is it?
j-rod+my loose theory comprised in my head earlier this morning about comps is that it should have a primary maintainer (or group of maintainers) through whom changes to comps should be filtered, with escalation to fesco in the event of a dispute...
ubertibbs+Our free java plugin can now run many, many more applets properly.
* nirik would like to note that he's going to try and organize/advertise/do some classroom sessions on irc soon. If anyone would like to teach any sessions, please see me after the meeting.
bpepple+allows java games that use javascript (like yahoo games) to run.
ubertibbs+liveconnect links the java plugin to javascript somehow.
j-rod+...but it seems we're talking about other stuff for the moment. :)
jwb+bpepple, sound right, thanks
bpepple+j-rod: sorry, back to you then we can talk about live connect.
j-rod+eh, either/or
j-rod+the liveconnect thing sounds more pressing
bpepple+no, the floor is  yours, we should have plenty of time to discuss both.
jwb+j-rod, so like a comps SIG
j-rod+ok then
j-rod+jwb: that'd work
j-rod+and/or perhaps only w/uberpackager status could commit to comps
j-rod+only people w/
jds2001+i think that's by default now
j-rod+ah, ok
jds2001+since they don't own comps, a normal packager wouldn't be able to commit to it.
jds2001+nirik: keep me honest here :)
bpepple+jds2001: that sounds correct.
* nirik goes to look. comps is weird... it's not a package
j-rod+notting seemed like a prime candidate to be the comps "package maintainer"
bpepple+j-rod: is notting interested in doing it?
* j-rod pokes notting
notting+um... sure.
notting+fyi, for things like gnome-desktop, kde-desktop, fonts, etc. i don't think a filter is needed
j-rod+notting: don't want to put words in your mouth, but that was sort of what I thought I was hearing from you during discussion yesterday
Kick_+notting:  I'm willing to help if you run out of time
notting+i was half-joking, but if you need someone, i'll do it
jds2001+we appointed notting the Grand Arbiter of Compsitude
f13+wait wait
j-rod+I think a filter for gnome-desktop and kde-desktop etc is still valid
f13+why do we need a filter on comps?
f13+do we not have enough people watching the commit diffs and correcting misbehaviour?
j-rod+to prevent people from willy-nilly adding default packages
f13+j-rod: I'd rather correct bad behaviour than prevent good behaviour (:
j-rod+that could well *be* the filter, I suppose
wwoods+f13: apparently, no
notting+f13 has a point... we haven't really had willy-nilly changes
j-rod+but I don't know that anyone is formally responsible for it
ubertibbs+Could comps be generated from some other interface?
f13+j-rod: technically I think releng is responsible for comps
wwoods+even if it's not been necessary it'd still be good to have a well-defined Review Procedure if it becomes necessary
f13+at least I review the changes to it
jwb+notting is in rel-eng
jwb+so, grand arbiter
wwoods+the proposed procedure was: notting looks at it, and if he doesn't like it, you get a poke in the eye with a sharpish stick
jwb+are we solving a problem that doesn't need solving?
nirik+the big problem is that most people don't add stuff to comps right? will this SIG/notting then go and add all the stuff that isn't now, but should be?
wwoods+discussion about the size/composition/sharpness of the stick can go to -devel-list
notting+nirik: that's above and beyond what i want to sign up for
jwb+nirik, yeah i think that's the issue.  it's that people don't add
j-rod+also, I think part of why we haven't seen many bizarre changes to comps is that we don't advertise that it *can* (and/or should) be modified when a new package hits the distro
nirik+notting: yeah, I don't blame you, but isn't that the issue we want to solve?
f13+nirik: I'm not sure, I came in late.  I just didn't like the idea of having a gateway to comps be put in place.
bpepple+nirik: I think we need to better clarify on the comps wiki page what should be included.
jwb+there's a lot of crap that just doesn't need to be in comps
f13+j-rod: it's listed in the wiki page 9:
j-rod+yeah, I know, but I wonder how many people gloss over it
jwb+why can't you have a per-package 'comps' file in CVS, and then a tool goes through those and generates the global comps file from it
f13+jwb: what problem does that solve?
jwb+comps sucks
j-rod+f13: (oh yeah, that should have been "don't advertise enough", I know its at least mentioned)
jwb+unless you can create new comps groups, i don't think it's really worth chasing down...
f13+so I guess what I'd like to know is what problem are "we" trying to solve here
notting+the parts where i see maybe there being a worth for some process are 1) adding new groups (outside of langsupport)  2) modifying base & core
* nirik nods
j-rod+I think its twofold: get more stuff into comps that is missing, but don't screw things up in the process
bpepple+j-rod: +1
j-rod+(particularly in base & core)
nirik+so, perhaps we could add everything to comps, but hide stuff that shouldn't be end user visible? or come up with some better guide for when adding to comps is required and filter all existing packages against that?
f13+notting: fair enough.  That could just simpley be 'ask before modifying', and continue using cvs commitdiffs as review points and correct any bad action.
notting+nooooo ... adding everything is not the way
j-rod+yeah, not everything belongs
f13+nirik: the hard part is that it's a judgement call on whether the package should be uservisible or not
j-rod+no point in listing most libraries
f13+nirik: and that judgement most often lies with the maintainer of the package.
nirik+sure, but part of the issue is "has this package been looked at to see if it needs to be added and then decided it's not" or not.
nirik+so we have no way of knowing how many we are missing where no one looked to see if they should be added.
f13+I know!  A needs comps flag in bugzilla!
bpepple+nirik: shouldn't the package maintainer be doing that when they import a new package
f13+(on the review ticket)
notting+f13: *whack*
j-rod+it sort of sounds like there ought to be a one-time project, going through all the packages, and making a judgment call on them, and adding them to comps, then try to be more proactive with new packages being evaluated
nirik+bpepple: yes, but I think it's a step many forget.
nirik+j-rod: yes, thats what I think
Kick_+can we make it part of the review process for new packages ?
f13+for a more realistic answer, maybe a bit of metadata in pkgdb ?
nirik+Kick_: humm... possibly... but again that might not catch all of them if the reviewer doesn't mention it...
bpepple+Kick_: yeah, that could help.  ubertibbs, you have thoughts on that?
j-rod+make it a MUST component for package review: proposed comps group, or justification why it shouldn't go in comps at all
nirik+I suppose we could also mention it when processing cvs...
nirik+cvs done, and remember to check if you should add this package to comps.
jds2001+j-rod: what about libs and other non-user visible stuff
nirik+(but of course that only gets new packages, not the current big set)
jds2001+where does python-bugzilla go for example?
jds2001+there's a CLI piece to it, but mostly it's a python library
notting+jds2001: shouldn't go in
mdomsch+jds2001, developer tools
notting+but if we add every python-*/perl-* to comps, it will be unmanageable
mdomsch+wherever fedora-packager
jds2001+oh, for sure - there's actually a user-visible piece to python-bugzilla though
notting+(who installs python and perl modules via browsing groups, as opposed to either a) by deps b) search)
jds2001+not so for most python-/perl- packages
j-rod+jds2001: as I said before, I don't think libs belong in comps for the most part, so its an easy justification for the packager/reviewer
j-rod+(for it to not be in comps)
ubertibbs+Honestly I don't know what the rules are for comps.
dgilmore+could we have pkgdb manage comps
ubertibbs+But we could certainly make proposing the relevant comps group(s) part of the package submission process.
ubertibbs+I'd like to see actual documentation first, though.
ubertibbs+dgilmore: I was asking that earlier.  Have something else generate comps.
jds2001+sure, is the documentation piece in FPC's domain?
dgilmore+ubertibbs: pkgdb seems like that logical place.
j-rod+ubertibbs: i.e., a "Here's what should and should not go in comps, where and why" doc?
f13+dgilmore: what problem does that solve though?
dgilmore+have it manage cvs and comps
f13+dgilmore: it just seems that you're moving the problem from one untouched place to another untouched place.
ubertibbs+j-rod: Yes.
dgilmore+f13: adding cvs branchs have a checkbox  add to comps  with adrop down of groups
bpepple+ubertibbs: I believe the comp.xml wiki page does that, though we should probably expand on what's there a bit more.
f13+dgilmore: how many maintainers actually look at pkgdb though?
f13+dgilmore: I'd bet the majority of them never even see it
j-rod+ubertibbs: I'd be game for taking a crack at such a doc, probably for submission to FPC
dgilmore+f13: every one when we finally get cvs admin requests handled through it
j-rod+bpepple: the existing comps page in the wiki is... a bit sparse...
dgilmore+f13: i think we would ned to tie in cvs admin and comps to land at once
f13+dgilmore: they'd only need that for changes after the initial import through right?
bpepple+j-rod: agreed.  I think one of the first things we need to do is fix that.
dgilmore+f13: initial import and changes
f13+dgilmore: so you're going to have an admin create the pkgdb entry, just to have the user go and fiddle with it to set up the initial settings?
dgilmore+f13: no
notting+bpepple: i'll add some bits there that should help clear up some things
f13+also, we need comps to live in CVS for translations
f13+unless you some how hook up cvs and pkgdb comps entries to translations..
bpepple+notting: thanks.
dgilmore+f13: the user when they get a package approved will make the request in pkgdb  point it at the bug report and give them the comps option then
ubertibbs+Honestly I think the CVS stuff is done out of order, and the package reviewer should be doing the import upon approving the package, but that's a huge change.
jds2001+dgilmore: how do you 1) make new groups 2) add a package to more than one group in this pkgdb proposal?
dgilmore+f13: once they make the cvs admin request and admin will go and approve the request and then branching will happen in the background
* jds2001 doesn' really see the UI for either of those things being pretty
dgilmore+jds2001: AFAIK multiple groups are not allowed,  but if we do we need to use an input type that allows selecting multiple options
dgilmore+and adding new groups would need an inteface for
f13+dgilmore: make the request /where/ in pkgdb.  There is a chicken/egg issue.
dgilmore+f13: in a new package page
f13+dgilmore: does any of this exist yet?
dgilmore+f13: no but its in the works
dgilmore+abadger1999: please let me know if im mis-interpretiung how we plan to manage cvs requests in pkgdb
f13+and why would we make a user use one system (bugzilla) do do all the review and such, then make them copy/paste information into yet another tool (pkgdb) to get the package system setup, then go to a third tool (cvs) to actually import the package?
abadger1999+The best proposal I've seen regarding this was something nim-nim posted long ago -- pkgdb has comps-like information but comps itself is generated from a subset of that information defined by the distribution/rel-eng.
f13+if anything, pkgdb should just read from bugzilla when a review bug gets approval
j-rod+notting: holler at me if you want additional input for changes to that wiki page
f13+and do the setup automagically
f13+maybe even including pulling down the srpm from the bugzilla to do the initial import for the user.
abadger1999+dgilmore: I think you've got it about right.
dgilmore+f13: ideally they will enter a bug number and it will get package name etc from bugzilla.
jds2001+dgilmore: that assumes that the bug subject is sane.
dgilmore+f13: and they will fill in in pkg db owner, comaintainers initiallcc etc
ubertibbs+BTW, dbhole did drop by to talk about the liveconnect thing if we could squeeze in a few minutes between brainstorms.
f13+yeah, I'm not even in fesco, don't let me derail this.
ubertibbs+dbhole: I let folks know you wanted to publicize liveconnect, but I don't really know more about what's going on.
bpepple+alright, so in the interim, we're going to improve the comps wiki page to better clarify what should be included.
ubertibbs+I hope he hasn't left....
bpepple+and we'll discuss maybe adding it as a must item during reviews.
j-rod+once we're happy with that wiki page, I think we're looking for volunteers to look for packages to compsify
dbhole-ubertibbs: nope, here.. and thanks. Yeah, it was too late to put it in the feature list, but I do think we should publicize it, as it is a nice feature that will finally allow people to move away from Sun's java plugin
bpepple+j-rod: sounds good I'll add that bit to my summary also.
bpepple+anything else? otherwise we can move on to dbhole's feature.
j-rod+I think that and where comps should live are two separate discussions
j-rod+now I
j-rod+...am done
bpepple+j-rod: thanks.
bpepple+ok, dbhole floors your.
--- bpepple changed topic: FESCo - Liveconnect feature.
dbhole-bpepple: Thanks. Alright, so here is the thing: For Fedora 10, we have been working on this new feature called Liveconnect. It allows Javascript from a browser to access Java (applets, and vm) and viceversa
dbhole-It is used by sites like yahoo games, absolute poker, and many bank sites
dbhole-until now, anyone wanting to use that in Fedora had to use Sun's proprietary plugin. Liveconnect does away with that, and offers a fully Open Source solution
nirik+dbhole: excellent work. ;)
bpepple+dbhole: Is this feature done, and testable in Rawhide?
nirik+I suggest a release note at least?
dbhole-bpepple: It is done, and it is in rawhide. I sent a note to fedora-test-list a few days ago asking people to go at it
bpepple+dbhole: cool.  So, to me this definitely should be something we should be trumpeting when we release F10.
dbhole-nirik: Thanks.. and yeah it is in release notes ... had to brag about it somewhere :)
nirik+dbhole: is there any feature page for it?
j-rod+out of curiosity, is there a feature page for it? and if not... heh
dbhole-nirik: Nope, when I found out that the feature list was locked out, I didn't create one. I can quickly set one up within a couple of hours though.. since everything is already done, it is just a matter of typing it out
* nirik wonders if this messes up docs adding something like this... and it is after the freeze.
bpepple+poelcat: what are you thoughts on having dbhole creating a feature page for this?
j-rod+late though it is, since its done and really does sound like something to brag about, we ought to add this as a pimped Feature
j-rod+although... what about people who had their features dropped 2 weeks back because they weren't complete...
bpepple+j-rod: I tend to agree with you also.
bpepple+j-rod: yeah, that's what I'm torn about.  Those folks we booted since they weren't complete would be justified in being pissed about us.
* nirik is unsure what process the completed features go thru for docs... they might already have been written up, etc...
j-rod+yeah, hard to say where to draw the line between one feature and another wrt value, but to me, the fact users can web browse all these java sites w/a 100% open stack is something to shout about much more so than some new package group for a niche group or something
bpepple+j-rod: I think either way we go folks are going to be unhappy, but I really think this is something we should be pimping.
j-rod+if for example, this were a new light-weight desktop env., I'd say sorry, too late
jds2001+right, and if it's complete, I've got no issue adding it assuming that the other dependent groups are fine with that.
j-rod+bpepple: agreed
jds2001+me too
bpepple+ok, so is anyone against making this a feature, providing that some of the dependent groups (like docs) doesn't have an issue?
dgilmore+i think its ok,  but i also think that dbhole should have spoken up sooner
j-rod+its a feature that really speaks to the core philosophies of what makes fedora fedora
dbhole-If it makes it any easier, there are also no new packages introduced for this feature. Just an update to an existing package, that now installs a different Java plugin.
nirik+bpepple: +1 here.
j-rod+do it.
dbhole-dgilmore: Yeah, I will accept responsibility for that one :/ That said though, there is no way we could have submitted this as a feature by the September feature freeze. The plugin was too unstable then, and we were not sure if it would be ready for F10
Kick_+fine with me, +1
bpepple++1 to adding liveconnect as feature.
jds2001+stickster, quaid: what does docs do for features and is adding one this late going to cause issues?>
bpepple+alright, so I don't see anyone objecting to this, so I'll check with poelcat and see if it's to late for any of the other groups.  If its not, I'll contact dbhole to write up the feature page.
dbhole-bpepple: Alright. I have already started writing the feature page locally. When/If I receive the OK from you, I will go ahead and publish it on the wiki
bpepple+dbhole: sounds good.
bpepple+anything else? otherwise we can move on.
--- bpepple changed topic: FESCo meeting -- Free discussion around Fedora
dbhole-nothing from me.. thanks everyone!
bpepple+aright, anything else to discuss? if not, we can probably wrap-up for this week.
dgilmore+dbhole: for future reference propose it also
* nirik would like to note again that he's going to try and organize/advertise/do some classroom sessions on irc soon. If anyone would like to teach any sessions, please see me after the meeting.
bpepple+dgilmore: +1, we can always drop features if they're not ready.
bpepple+nirik: what kind of sessions are you looking for?
nirik+end user focused fedora topics... see http://www.redhat.com/archives/fedora-list/2008-October/msg00179.html
sticksterjds2001: re: docs for features -- we take what's included in the release notes section of the feature page and get it included in the official Release Notes, if not already done.
dbhole-dgilmore: Yes, I will definitely be more proactive on this sort of stuff in the future :)
nirik+I was hoping to do some this weekend, but got swamped... so probibly weekend after this we will do a few and see how it goes.
dgilmore+dbhole: thanks.  We can always drop a feature.  much harder and more contriversial to add it later
bpepple+stickster: so, is it to late for a new feature page to be added?
sticksterbpepple: To docs? Certainly not
sticksterWe can make content changes for a little while still
sticksterand have them land in the F10 GA
bpepple+ok, cool.  so, dbhole it looks like we good to go for you to do a feature page on liveconnect.
* quaid looks in
sticksterdbhole: Please alert the fedora-docs-list when you have something for us to look at -- or better yet, feel free to edit the Docs/Beats/Java page on the wiki directly
sticksterWe'll take care of editing, cleanup, etc.
quaid++1 to edit beat directly
bpepple+alright, time to put a fork in this meeting.
* bpepple will end the meeting in 60
quaid+is there a Feature page?
quaid+we'll need that for Marketing, etc. as well
bpepple+quaid: not yet, but dbhole is working on it.
* bpepple will end the meeting in 30
* bpepple will end the meeting in 15
bpepple+-- MARK -- Meeting End
bpepple+Thanks, everyone!
dbhole-stickster, bpepple: Great! I will publish it as soon as I am done and send the note
sticksterdbhole: Super
sticksterAnd nice meeting you in Toronto by the way
bpepple+anyone got a log of this meeting they could forward to me, since I lost the first quarter of the meeting?
sticksterbpepple: I do
bpepple+stickster: thanks!

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