--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process | ||
bpepple | FESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren | |
---|---|---|
Hi everybody; who's around? | ||
warren | hi | |
* jwb is 1/2 here for a bit | ||
dwmw2_HIO is | ||
nirik is here, but is running over to get coffee, back in a sec. | ||
warren | I guess this is my last fesco meeting ever? | |
* jeremy | ||
bpepple | warren: you don't have to be on FESCo to join the meetings. ;) | |
bpepple | ok, I see seven FESCo members so we can probably get started. | |
--- bpepple has changed the topic to: FESCo-Meeting -- new maintainer containment update -- sadmac2, abadger1999 | ||
bpepple | abadger1999 or sadmac2 about? | |
sadmac2 | bpepple: here | |
bpepple | you want to take the lead on this? | |
abadger1999 | Yep. | |
sadmac2 | Ok: | |
So, we are getting ready to execute on the new maintainer containment proposal | ||
There's 3 steps to this: | ||
1) Rename cvsextras to packager (mostly a cosmetic change) | ||
2) Add ACLs for the new uberpackager group to all packages | ||
3) Add all current sponsors to the uberpackager group | ||
oh, also 4) remove acls for regular packager group for all packages | ||
5) ??? 6) Profit. etc. etc. | ||
* dwmw2_HIO likes (4) | ||
sadmac2 | dwmw2_HIO: this was the purpose of all this | |
dwmw2_HIO | er, I think | |
warren | we will really call it uberpackager? | |
dwmw2_HIO | no | |
sadmac2 | warren: ys | |
as of now | ||
dwmw2_HIO | it _has_ to be überpackager | |
notting | 'remove acls for regular packager' == 'open for all', or 'no longer open'? | |
ianweller | does FAS like the umlaut? ;) | |
sadmac2 | dwmw2_HIO: we tried. there are pieces of software involved that hate unicode | |
notting | i.e., have non-sponsors effectively been downgraded? | |
dwmw2_HIO | it should be open for all, right? | |
sadmac2 | notting: they will be open to all uberpackagers and their owners | |
abadger1999 | Really... 4? | |
dwmw2_HIO | er, isn't that a backward step? | |
we want all packages to be open to all people. Except perhaps to a few 'junior packagers' who can only touch their own | ||
sadmac2 | notting: the process for getting sponsored for uberpackager is going to be trivial. within hours anyone who ever really needed the access will have it | |
jeremy | dwmw2_HIO: the problem is amongst our existing set of packagers, how do you determine who are the junior vs not? | |
sadmac2 | dwmw2_HIO: Its not going to be terribly hard to become an uberpackager | |
dwmw2_HIO | ok, so _most_ people who care should be 'überpackagers'? | |
fine. Then it's just that I was a bit mislead by the terminology | ||
jeremy | dwmw2_HIO: by putting the sponsors there (and giving sponsors the ability to put other people in teh group), that should work itself out to the "correct" state pretty quickly | |
warren | how about uberpackager requires a sponsor to upgrade them? | |
sponsors are approved only by fesco vote | ||
and we have a good number of existing sponsors | ||
abadger1999 | sadmac2: Is 4 really going to happen or is that something for individual package maintainers to decide? | |
sadmac2 | warren: uberpackager requires an existing uberpackager to approve | |
warren | that's fine to me | |
sadmac2 | abadger1999: it is, in preparation for the mass ACL open. We can't do that without the containment line | |
warren | then make uberpackager == sponsors at first | |
notting | sadmac2: so, the acl open is actually 'acl open to uberpackagers'? | |
abadger1999 | sadmac2: Why can't mass acl open open packages to uberpackager? | |
sadmac2 | notting: precisely | |
sadmac2 | abadger1999: then permissions become very complicated and people get confused | |
drago01 | sound worse than what we have know ... less people with access to everything | |
sadmac2 | abadger1999: the idea is packagers can ONLY touch packages they are maintainers of | |
spot | that seems... wrong. | |
dwmw2_HIO | I agree | |
spot | i have cvsextras open on my packages specifically so others can make changes if they need to | |
dwmw2_HIO | ideally, all packagers should be able to touch all packages where appropriate | |
sadmac2 | spot, dwmw2_HIO: I stress again that it will not be hard by any stretch of the imagination to become an uberpackager | |
spot | even still. | |
dwmw2_HIO | a lot of people have deliberately opened the ACLs on their packages | |
_those_ packages should remain open to all packagers | ||
sadmac2 | you just have to find someone who is, and ping them. thats it | |
spot | if you want to temporarily contain people, that is fine | |
dwmw2_HIO | it should be a kind of 'probation period' for new maintainers | |
spot | (new people) | |
abadger1999 | sadmac2: Could you explain who is in uberpackager and who is in cvsextras? | |
ideally... not at first. | ||
dwmw2_HIO | and 'überpackager' status should actually be the norm. You shouldn't really have to jump through hoops for it -- however simple those hoops actually are | |
sadmac2 | abadger1999: uberpackager is anyone who wants to be there, and has convinced at least one person who is there already that they are not an idiot | |
spot | I see three groups here: 1. New Packager (can only touch their package) 2. Packager (can touch anything with open ACLs) 3. Super Packager (can touch anything) | |
dwmw2_HIO | can we do a separate commits-list for commits made by people who aren't maintainers? | |
sadmac2 | dwmw2_HIO: so you just want it on a timeout | |
? | ||
dwmw2_HIO | that would help to improve the security situation where we are worried about malicious commits to other packages | |
sadmac2 | spot: the need for group 3 hasn't really arisen yet | |
dwmw2_HIO | sadmac2: maybe not _actually_ a timeout. But something like that | |
sadmac2 | spot: packager and uberpackager are 1 and 2 | |
spot | sadmac2: actually, it has. secondary arch groups are in 3. | |
2 is what everyone is now | ||
abadger1999 | spot: Group 3 exists but is not separate from cvsadmin. We could make that group at any time really... populating the initial sponsors would be the only hard part. | |
sadmac2 | spot: well we're moving people back to 1 and creating a new 2 | |
notting | if we're intending to have a group 3, then we probably shouldn't call 2 uberpackager | |
spot | sadmac2: which is what i am opposed to. | |
everyone in the system now should stay in 2 as is. | ||
drago01 | example where group 3 would help: https://bugzilla.redhat.com/show_bug.cgi?id=455734 | |
buggbot | Bug 455734: low, low, ---, Parag, NEW , broken dep in rawhide | |
* sadmac2 really wishes jesse was here for this | ||
spot | if you want to create a containment for new packagers, thats fine | |
bpepple | btw, this (uberpackager) is something we decided awhile back about in FESCo. sadmac2 merely implemented it. | |
dwmw2_HIO | it should be 'probation', 'packager', 'überpackager' | |
sadmac2 | spot: bpepple is correct | |
spot | dwmw2_HIO: lets not paint the bikeshed | |
* sadmac2 searches for meeting minutes | ||
warren | I care less what the group names are called | |
dwmw2_HIO | spot: there was a technical distinction there, not just the names | |
warren | but I think the 3 levels is a good idea. | |
nirik | I think the only point of contention is if 2 should have the existing cvsextras or 1 should | |
abadger1999 | So here's the goals I heard from f13: 1) Have a way to contain new maintainers 2) Get more packagers to open the acls of their packages to (nearly) all the other packagers | |
spot | bpepple: we really decided that packagers won't be able to touch things with open acls? | |
dwmw2_HIO | I mean, we shouldn't be moving people back from (2) to (1). | |
warren | it depends if packager is the lowest (probationary) level or not. | |
bpepple | yeah. we decided that it was easy enough for sponsors to upgrade the accounts of people that wanted access to all packages. | |
nirik | many current cvsextras people will not care, they only look at their own packages ever. | |
* spot shakes his head | ||
warren | I think packager (former cvsextras) should be level 2. | |
bpepple | one moment, and let me see if I can find the minutes of the meeting we discussed this in. | |
nirik | warren: +1 | |
abadger1999 | 1 is easy to envision. I think f13's idea was if we put everyone in 2 and have an immediate shaking out of sponsors pushing people into 2 we'd build confidence for cautious maintainers to allow 2 to happen. | |
sadmac2 | I think we're all overestimating how important level 2 is | |
* spot notes that this is a pointless exercise, if we do this, i will promptly elevate everyone in sight to l2. | ||
bpepple | spot: I believe it was at this meeting: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20080605 | |
dwmw2_HIO | I do appreciate that if it's _easy_ to move to (2) from (1) then it's mostly cosmetic | |
sadmac2 | I'm betting 95% of maintainers won't even notice | |
jeremy | abadger1999: correct | |
dwmw2_HIO | but we want to _encourage_ participation and make people think it's easy | |
there are a lot of people who just wouldn't ask, unfortunately. | ||
spot | the normal state for packagers should be uncontained | |
warren | Do we at least have agreement of the 3 level structure? | |
spot | not contained by default. | |
dwmw2_HIO | it's sad but true -- we exclude people just by making them ask for it | |
warren | dwmw2_HIO: +1 | |
notting | i think the idea is that if you make an actual process of having elevated privleges, you make it more likely that maintainers with ACLs will remove them | |
sadmac2 | ah, I see bpepple linked already | |
nirik | also, someone requesting will be more likely to use that to fix/help than someone who just happens to have it without really knowing it. | |
jeremy | spot: and if that's the normal state, then we haven't changed a thing from where we are today and the maintainers who don't want to open acls are going to continue to not want to | |
dwmw2_HIO | notting: I suppose that's a useful goal. Do we have stats on how many people have removed their ACLs? | |
and their reasons for not doing so? | ||
jeremy | nirik: that's a good point I hadn't even thought of | |
spot | jeremy: i'm not against new maintainer containment on a temporary basis | |
nirik | dwmw2_HIO: I have bugged any new cvs requests with closed cvsextras about it... most have said "too many people in that group" or the like for why they want to do it. | |
spot | but i am against restricting people who get past unnecessarily | |
sadmac2 | spot: well what's the deciding factor for who's "ready?" | |
dwmw2_HIO | another way to assuage their concerns might be a special commits list for 'non-maintainer commits', which would have a bit less traffic and a few more eyes than the main commits list | |
and a threat of demoting people to 'probationary packager' status (or whatever we call state (1)) if there are bad commits on that list | ||
and/or maybe non-maintainer commits could be Cc'd to the sponsor of the committer | ||
there are a bunch of ways to make people happier about opening up the ACLs. do we really need to do _this_ one this way? | ||
spot | sadmac2: i think a period of time along with the conditions that dwmw2 is describing are sufficient | |
abadger1999 | So here's a question: Will a separate group actually make any of these maintainers comfortable enough to open their acls? Or is it still going to be... there's too many people in that group... | |
sadmac2 | spot: what about a combination: after a period of time in stead of just getting promoted, fedora-devel-list just gets poked informing everyone that these people are still packagers | |
spot | i think if we do this, we will end up with a lot of people who can no longer use open acls, thus defeating the point of opening things up. | |
sadmac2 | with the expectation that the worthy be promoted | |
abadger1999 | dwmw2_HIO: I sort of like that... although we already have mail from the commit going directly to the maintainers of the package. Will another mailing list help? | |
dwmw2_HIO | abadger1999: any way for them to filter it differently would help. Doesn't have to be another list | |
sadmac2 | I think the packaging system is noisy enough | |
dwmw2_HIO | could just be a header X-Fedora: NON MAINTAINER COMMIT BY dwmw2! You might want to check if he's broken it | |
nirik | abadger1999: no way to be sure... we could generate a list of them and ask... | |
dwmw2_HIO | that would let people highlight non-maintainer commits. | |
bpepple | sadmac2: +1 | |
dwmw2_HIO | I suspect that if we really do make it easy to obtain state (2), then the 'too many people' argument would still apply | |
if all you have to do is _ask_, then the only people who are excluded are the people who weren't going to commit to other packages _anyway_ | ||
except by accident in a fit of drunkenness, perhaps | ||
but I haven't done that for years | ||
bpepple | If we're going to change the requirements of new maintainer containment, I would like to see a proposal instead of doing it ad-hoc during the meeting. | |
sadmac2 | dwmw2_HIO: the individual can still say "um, no" but its expected that's rare | |
abadger1999 | dwmw2_HIO: I think your suspicion may be correct :-( | |
nirik | bpepple: agreed. | |
dwmw2_HIO | if my suspicion _is_ correct, then we don't actually gain much by pushing people from (2) to (1) right now. | |
dwmw2_HIO | bpepple: yes, but we can get to a better proposal after we've talked it through and reached some form of consensus. | |
drago01 | what about everyone can commit and only people in group "whatever" can build? | |
sadmac2 | drago01: or tag | |
dwmw2_HIO | I think that would also encourage people to open up commits, yes. | |
nirik | the proposal's goal is to contain new maintainers... not all existing maintainers. | |
sadmac2 | that makes cvs acls more complex | |
they're buckling as is.... | ||
dwmw2_HIO | build. tag. push. Or something | |
sadmac2 | not to say we can't | |
abadger1999 | build needs work in koji. | |
tag is only so so since koji will build from HEAD. | ||
(Just scratch build, though.) | ||
sadmac2 | abadger1999: I thought koji built by tag | |
dwmw2_HIO | I think there are a lot of ways we can encourage people to open their ACLs, and moving existing packagers from (2) to (1) possibly _doesn't_ achieve it as much as we'd want it to anyway. | |
abadger1999 | sadmac2: Yes. But HEAD is a tag for this purpose. | |
drago01 | you can commit anything and do make scratch-build | |
dwmw2_HIO | leaving the other encouragements aside for now, let's get back to the containment. Is the only question whether we want to move existing packages from (2) to (1)? | |
warren | packagers | |
? | ||
dwmw2_HIO | s/packages/packagers/ | |
warren | Does this mean we will indeed have 3 levels? | |
dwmw2_HIO | I think 3 levels makes sense | |
warren | Let's come to agreement on that part first because it is easier? | |
dwmw2_HIO | (1) is only their own packages. (2) is all open packages, (3) is all closed packages too | |
* nirik nods. 3 levels is fine... the 3rd right now is cvsadmins and secondary arch leads, right? | ||
drago01 | rel-eng | |
abadger1999 | two levels (third level is sort of there but hidden -- cvsadmin, secondary arch) | |
sadmac2 | I don't think 3 is even in the scope here. It exists, we're not changing it | |
dwmw2_HIO | right | |
warren | OK, so that seems like agreement. | |
Now s/cvsextras/packager/ is level 1 or 2? | ||
dwmw2_HIO | so it's really just a question of whether we move existing packages from (2) to (1) ? | |
notting | you typoed again | |
dwmw2_HIO | you should be used to it by now | |
drago01 | packagers are just packages for dwmw2_HIO ;) | |
* dwmw2_HIO recompiles drago01 for powerpc | ||
dwmw2_HIO | er, I mean ia64. | |
drago01 | ;) | |
dwmw2_HIO | since I'm actually sitting _in_ an Intel office right now.... :) | |
warren | If s/cvsextras/packager/ becomes level 2, then acl's don't change at all for them. Then we need a new group for level 1, where they have access only to packages they own. Is this really complex to implement? | |
sadmac2 | warren: its proven a pain in the ass to mess with the groups | |
abadger1999 | warren: Not too complex. | |
warren | sadmac2: elaborate? | |
notting | i think the biggest issue with the new group is determining who goes in it to start off with | |
abadger1999 | Need thought to make sure it works but what I'd do is: | |
notting | because certainly there are people in cvsextras now who probably should be there instead | |
sadmac2 | warren: there's quite a bit of ugly hardcoded things in pkgdb | |
abadger1999 | add all current cvsextras => uberpackager. Rename cvsextras and uberpackager as appropriate. | |
Should be fine. | ||
warren | We need to come to agreement on *something*. | |
dwmw2_HIO | if there are really people we want to exclude (who'd be offended if we just named them and said so) then we can invent heuristics for deciding whether each existing packager goes into (1) or (2) | |
and then 'promote' people as required afterwards | ||
nirik | we could possibly gather a list of all people who have commited to a package not their own and add them to 2? seems a lot of effort for not much tho | |
dwmw2_HIO | proposal: Most (if not all) existing packagers should go into group (2), which is currently called überpackager but might want renaming. | |
sadmac2 | The name is a bikeshed. Furthermore its a bikeshed that has to be painted upside down in zero gravity with special teflon paint thats made by monks in egypt | |
sadmac2 | leave it alone, for all of our sake | |
It has a coat on it | ||
dwmw2_HIO | whatever | |
proposal: Most (if not all) existing packagers should go into group (2) | ||
warren | Shouldn't we decide upon 1) a dividing line and 2) who gets to promote them? | |
* nirik is fine with that, but hopes it won't mean that closed acl packages would stay closed. | ||
nirik | how many packages do we still have with closed acls? | |
sadmac2 | not sure | |
nirik | if we are trying to get those maintainers comfortable with opening things up, shouldn't we ask them what we need to do to get them happy and comfortable? | |
or do we care? | ||
sadmac2 | part of this proposal was that we would open all of them afterward (with an opt-out checkbox in pkgdb if you really didn't want that) | |
nirik | at least some of them may be happy with just new maintainers contained. | |
some of them may want the group of commiters to be smaller | ||
abadger1999 | nirik: I think that would be good. I talked to one during FudCON which would support dwmw2_HIO's suspicion (only one data point though) | |
* nirik has a hard time telling as he has all his open. | ||
* bpepple sees that we've spent 45 minutes discussing this. | ||
warren | What are the points that we do have agreement on? | |
abadger1999 | warren: Having a further level. | |
dwmw2_HIO | bpepple: feel free to put your chairman hat on and repeat my proposal in a way that makes people vote on it :) | |
abadger1999 | warren: New maintainers go in the lowest level | |
dwmw2_HIO | +1, btw | |
abadger1999 | warren: Undecided is: Where do present maintainers go? And How do we transition people from lowest level to second level? | |
warren | Let's decide on both now. | |
dividing line must be simple and imperfect so we'll actually decide now | ||
* nirik wonders if we are going to decide on anything here. | ||
warren | Starting membership in level 2: "owns 8 packages on X date" + FESCO/releng | |
bpepple | ok, so I see two proposals here. 1) The original proposal we approved back in June, 2) New proposal to move all current cvsextras member to the uberpackager group, and have new maintainers join the packager group. | |
* nirik wonders if the rest of fesco is off having fun instead of providing input here. ;) | ||
bpepple | Does that sound correct? | |
nirik | bpepple: whats the link to the orig proposal from 1? | |
LinuxSri | hello | |
warren | perhaps we need to follow up on list. we don't have quorum? | |
* bpepple sees if he can find the link. It's summarized here though: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20080605 | ||
dwmw2_HIO | warren: that seems close enough to me. There's no point in arguing about details since we can move people. +1 to 'owns 8 packagers + FESCo/releng' | |
dwmw2_HIO | as an initial heuristic for it | |
warren | 'owns 8 packagers + FESCo/releng' is just an arbitrary, simple and imperfect line to draw so we can decide on something. | |
damn it | ||
8 packages | ||
* spot pwns 8 packagers | ||
warren | dwmw2_HIO: did you do that intentionally? I didn't type packagers at first. | |
=) | ||
* stickster points out that respect means not owning people | ||
nirik | thats fine for me +1 | |
spot | fwiw, that is ok for me as well (+1) | |
warren | seemingly we don't have enough people to vote? | |
notting | +8 | |
sadmac2 | stickster: what if they're noobs? can I still own noobs hardcore | |
? | ||
warren | Anyhow, the second part we need to decide: | |
Who gets to promote? | ||
Any existing level 2 member? | ||
jeremy | +1 I guess, although why we need to re-decide I'm still not quite clear | |
warren | Level 3 + FESCO + rel-eng? | |
* nirik thinks we need to redecide because people were unclear on what we decided last time. | ||
bpepple | jeremy: agreed, I don't see the point either. | |
+1 reluctantly. | ||
notting | jeremy: well, if it's just changing the initial population of $GROUP_NAME, consider it an amendment? | |
warren | Level 3 = Sponsors, FESCO, releng (possibly others)? | |
sadmac2 | warren: level 3 is outside the scope | |
warren: its there, we need not change it for this proposal | ||
warren | sadmac2: not exactly | |
Who gets to promote someone from level 1 to level 2 is important. | ||
abadger1999 | Adreed. Level 3 is outside of scope *and* was essentially decided last week. | |
sadmac2 | warren: if you're going to make that depend on level 3 don't redefine level 3 in the process | |
warren | What is level 3 currently defined as? | |
dwmw2_HIO | are sponsors all in level 3 (can commit to _all_ packages) ? | |
abadger1999 | (cvsadmin sponsor/admins can decide who is in level 3) | |
sponsors are level 2 at this point. | ||
and under the current proposals. | ||
nirik | we agreed before that sponsors can elevate people from 1->2. | |
I am fine with that. | ||
warren | but anybody who becomes level 2 is a sponsor then? | |
notting | eh, just sponsors seems fine to me. people need sponsored to get to level 1 anyway | |
nirik | warren: don't think so... sponsors are people approved by fesco to be packaging sponsors. | |
warren | ok | |
Are there any remaining disagreements then? | ||
Let's recap exactly what will happen? | ||
sadmac2 | first will be the cvsextras rename | |
bpepple | warren: please do, so it will make it easier when I write the meeting summary. | |
sadmac2 | then uberpackager will be seeded with the set we defined here and given appropriate acls everywhere | |
then we will remove acls for packager | ||
* nirik nods. | ||
warren | Then sponsors can go ahead and promote anyone they want? | |
* nirik would like a email to fedora-devel-announce outlining this entire thing if possible, so maintainers know whats going on. | ||
bpepple | nirik: agreed. | |
jeremy | nirik: I thought that was a given :) | |
warren | oh, one more amendment | |
Initial uberpackagers: owns 8 packages today + fesco/releng + sponsors | ||
(forgot sponsors earlier) | ||
abadger1999: could you generate a list of accounts who own at least 8 packages quickly? | ||
abadger1999 | warren: Do we want to include comaintainers? | |
warren | good question | |
abadger1999 | actually.... this may get tricky. | |
abadger1999 | Well... alright if we know that some people will be left out and will need to be leveled-up then it's okay. | |
warren | levelled up | |
bpepple | ok, anything else on this, or should we move on? | |
warren | hah | |
abadger1999 | (Thinking of desktop group, for instance, where they have opened acls so that everyone in their team can commit.... not relying on setting commit for the individual members) | |
abadger1999 | bpepple: Do you guys want me to include commaintainers? | |
warren | abadger1999: but those teams have a sponsor on their team | |
abadger1999 | and we can define that as either: has approveacls or has commit. | |
nirik | bpepple: move on++ (of course we are already over our time... but perhaps we should try to do some more things today) | |
warren | abadger1999: or... we include them in the initial | |
notting | bpepple: if they're comaintainers , they've already demonstrated enough knowledge that someone trusts them outside of their packages, so i'd count them | |
bpepple | yeah, I'm inclined to include co-maintainers. | |
also. | ||
nirik: do you mind if we bump your bodhi karma topic to next week? | ||
abadger1999 | k. I'll generate a list and send a link to the fesco-list. | |
nirik | bpepple: yeah, it's all solved I think. see lmacken's post. | |
bpepple | abadger1999: thanks. | |
nirik: great. | ||
nirik | bpepple: you can remove it from the schedule. | |
bpepple | ok, let's try to get through a few features before we wrap up. Is that alright with everyone? | |
btw, thanks for your time sadmac2 & abadger1999. | ||
abadger1999 | np | |
--- bpepple has changed the topic to: FESCo-Meeting Feature Acceptance -- https://fedoraproject.org/wiki/Features/ConnectionSharing | ||
bpepple | +1 this looks like a cool addition to NM. | |
notting | +1. is it really 100%? | |
nirik | +1 here. | |
bpepple | notting: Not sure. Don't have rawhide on my lappy. | |
nirik | I hope it works with wireless + EVDO. | |
dwmw2_HIO | I hope it works with IPv6 :) | |
jeremy | dwmw2_HIO: dcantrell has been making progress on ipv6 in nm afaik. but neither here nor there | |
nirik | also do some wireless cards still not do Master mode? | |
dwmw2_HIO | many don't | |
nirik | bonus points for the documentation there pointing to that same page. ;) | |
so it should detect those that can't and not show that option. | ||
mclasen | hey, I completed the section :-) | |
bpepple | nirik: nice. didn't notice that. | |
nirik | mclasen: indeed. ;) | |
drago01 | nirik: no thats why it uses IBSS (ad-hoc) and not master mode | |
EmpLinux | hi | |
nirik | ah ha. Missed that. | |
bpepple | ok, I see 3 votes for this feature. Anyone else want to weigh-in? warren, jeremy, spot, dwmw2_HIO | |
jeremy | +1 | |
dwmw2_HIO | +1 | |
warren | +1 | |
bpepple | hmmm, do we only have 6 fesco members here? That could be a problem..... | |
nirik | spot: you still around? want to chime in? | |
EmpLinux | hai i am applied for ambassadors. what i have to do/ | |
nirik | mclasen: do you know if this is fully implemented in rawhide already? | |
mclasen | nirik: to my knowledge, yes | |
hence the 100%... | ||
bpepple | ok, it looks like we don't have a majority of members still here, so we should probably wrap up the meeting. | |
nirik | mclasen: cool. Wonder if I can just grab NM from rawhide and try it on f9. | |
nirik | bpepple: yeah, if we can't approve features, no point in doing them. ;( | |
bpepple | nirik: agreed, sorta sucks. | |
alright, If there's nothing else let's end the meeting. | ||
* nirik nods. ;( | ||
* bpepple will end the meeting in 60 | ||
EmpLinux | :'( | |
nirik | perhaps we could do a special meeting early next week to just get thru features. | |
* bpepple will end the meeting in 30 | ||
stickster | nirik: +1 fwiwi | |
s/i$// | ||
drago01 | nirik: NetworkManager-0.7.0-0.10.svn3747.fc9 should have it | |
bpepple | nirik: I'm fine with that, but it might be best to wait for the new fesco, since they will probably have a better turnout. | |
dwmw2_HIO | when's the election? | |
nirik | bpepple: when is the election over? | |
jeremy | monday | |
stickster | dwmw2_HIO: now through the 22nd. | |
nirik | drago01: cool. will give it a whirl. | |
* 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!