=================================== #fedora-meeting: FESCO (2010-02-02) =================================== Meeting started by nirik at 20:01:34 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-02-02/fesco.2010-02-02-20.01.log.html Meeting summary --------------- * init process (nirik, 20:01:34) * #324 naming conflict: surf (nirik, 20:05:13) * LINK: http://koji.fedoraproject.org/koji/rpminfo?rpmID=1772215 (dgilmore, 20:17:40) * AGREED: surf package in Fedora should rename to surf-browser along with its binary and man pages, etc. (nirik, 20:21:44) * #320 Feature: Modprobe whitelist ( https://fedoraproject.org/wiki/Features/ModprobeWhitelist ) (nirik, 20:21:54) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=560084 (Kevin_Kofler, 20:23:37) * AGREED: Feature is approved. (nirik, 20:26:00) * #325 Fast-track Nonresponsive maintainer: Sindre Pedersen Bjørdal (sindrepb) (nirik, 20:26:11) * LINK: http://fpaste.org/NpTL/ (skvidal, 20:28:52) * LINK: https://www.redhat.com/archives/fedora-extras-commits/2010-January/msg00188.html (nirik, 20:31:32) * AGREED: Maintainer is unresponsive, will find (co)maintainers for his packages. (nirik, 20:40:43) * #327 Feature: StorageFiltering ( https://fedoraproject.org/wiki/Anaconda/Features/StorageFiltering ) (nirik, 20:40:59) * AGREED: Feature is approved. (nirik, 20:42:27) * #328 Feature: Dogtag Certificate System ( https://fedoraproject.org/wiki/Features/DogtagCertificateSystem ) (nirik, 20:42:45) * AGREED: Feature is approved. (nirik, 20:44:05) * #329 Feature: KVM Stable PCI addresses ( https://fedoraproject.org/wiki/Features/KVM_Stable_PCI_Addresses ) (nirik, 20:44:14) * AGREED: Feature is approved. (nirik, 20:46:14) * #330 Feature: Multipath install ( https://fedoraproject.org/wiki/Features/MultipathInstall ) (nirik, 20:46:22) * AGREED: Feature is approved. (nirik, 20:47:57) * #331 Feature: NetworkManager MobileStatus ( https://fedoraproject.org/wiki/Features/NetworkManagerMobileStatus ) (nirik, 20:48:08) * AGREED: Feature is approved. (nirik, 20:49:31) * #332 Feature: Virtx2apic ( https://fedoraproject.org/wiki/Features/Virtx2apic ) (nirik, 20:49:39) * AGREED: Feature is approved. (nirik, 20:51:39) * #333 Feature: VHostNet ( https://fedoraproject.org/wiki/Features/VHostNet ) (nirik, 20:51:47) * AGREED: Feature is approved. (nirik, 20:54:44) * #334 Late Feature Exception: NetworkManager Cmdline ( https://fedoraproject.org/wiki/Features/NetworkManagerCmdline ) (nirik, 20:55:33) * AGREED: Feature is approved. (nirik, 20:58:11) * #335 Late Feature Exception: NetworkManager Bluetooth DUN ( https://fedoraproject.org/wiki/Features/NetworkManagerBluetoothDUN ) (nirik, 20:58:24) * AGREED: Feature is approved. (nirik, 20:59:50) * Open Floor (nirik, 21:00:01) * Potentially Unmaintained script (nirik, 21:00:45) * fesco mailing list archives (nirik, 21:12:51) * AGREED: The fesco list is for nonpublic/sensitive matters. Use trac for public issues. Use of the private list will be kept to a minimum. (nirik, 21:31:43) * Open Floor 2: the return (nirik, 21:31:54) Meeting ended at 21:36:38 UTC. -- 20:01:34 <nirik> #startmeeting FESCO (2010-02-02) 20:01:34 <nirik> #meetingname fesco 20:01:34 <nirik> #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mjg59 20:01:34 <nirik> #topic init process 20:01:35 <zodbot> Meeting started Tue Feb 2 20:01:34 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:36 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:01:40 <zodbot> The meeting name has been set to 'fesco' 20:01:40 * skvidal is here 20:01:41 <zodbot> Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik notting pjones skvidal 20:01:48 * notting is here 20:01:50 <Kevin_Kofler> Present. 20:01:57 <ajax> party people in the house 20:02:05 * abadger1999 takes a seat in the bleachers 20:02:28 * skvidal has never been referred to as a party person 20:02:29 * pjones is here. 20:02:32 <skvidal> I'm sure y'all are all shocked 20:03:15 * dgilmore is here 20:03:25 <mjg59> Hello 20:03:39 <nirik> ok, I shall we get started? we have a fun packed agenda today. ;) 20:03:53 <skvidal> packed with fun 20:03:57 <nirik> cwickert: are you present? 20:04:00 <skvidal> an odd expression 20:04:16 <nirik> indeed. 20:04:49 <nirik> well, the followup item was about the 'surf' package, which cwickert was following. So, lets skip that and see if he's around later. 20:04:50 * gholms prepares coffee for everyone; it's going to be a long meeting. 20:04:58 <cwickert> sorry for being late 20:05:04 <nirik> ah, there he is. :) 20:05:13 <nirik> #topic #324 naming conflict: surf 20:05:13 <nirik> .fesco 324 20:05:16 <zodbot> nirik: #324 (naming conflict: surf) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/324 20:05:37 <cwickert> no news from the surf problem, cassmodiah tried to contact upstream, but 5 out of 6 mails bounced 20:05:48 <cwickert> and the last one didn't reply yet 20:05:56 <cwickert> next step is a bug in their tracker 20:06:07 <nirik> ok, so we wait further? or is there some action we should take? 20:06:08 <notting> 5 out of six upstream emails bounced? niiice. 20:06:21 <cwickert> last but not least I found yet another surf, a file manager for linux 20:06:37 <cwickert> IMO we should definitely go for renaming it 20:06:46 <mjg59> surf.sourceforge.net appears basically dead? 20:07:01 <cwickert> no, last release less than 3 weeks ago 20:07:11 <cwickert> but all emails bounce or give no reply 20:07:23 <mjg59> Oh, sorry - the project page has updates, their website seems stuck in 2003 20:07:47 <nirik> so surf the browser refuses to rename right? 20:07:52 <cwickert> right 20:07:54 <cwickert> right 20:08:14 <cwickert> surf browser includes several people and ALL refused renaming 20:08:43 <dgilmore> cwickert: i think we name it surf-browser 20:08:58 <cwickert> IMO there is no project that can claim the name 'surf', so IMO all packages should be renamed if they enter Fedora 20:09:04 <nirik> so, we can: a) wait more, b) rename our package, c) not rename our package, rename other things if they come along as packages. 20:09:27 <cwickert> I suggest to wait one more week for respons of the tracker. then rename if necessary 20:09:41 <mjg59> surf.sf.net appears to be considerably older than surf.suckless.org 20:09:48 <cwickert> right 20:10:06 <nirik> +1 to wait another week. 20:10:06 <dgilmore> which is why i say the browser is renamed 20:10:06 <mjg59> So, given that it's actively developed, I certainly don't see any onus on them to rename 20:10:07 <cwickert> and the other 3rd surf is even older, but dead it seems 20:10:26 <mjg59> For graphical tools, it makes little difference 20:10:30 <cwickert> dgilmore, they claim to be the project with the largest user base 20:10:42 <dgilmore> cwickert: doesnt matter 20:10:44 * skvidal thinks renaming the binary inside the distro is most sensible. 20:10:46 <mjg59> The binary may be surf-browser, but it'll still be in the menus as Surf Web Browser 20:10:46 <dgilmore> FIFO 20:10:52 <pjones> mjg59: yeah 20:11:00 <mjg59> So just rename the browser binary and move on 20:11:10 <nirik> but leave the package in fedora as 'surf' ? 20:11:20 <dgilmore> nirik: surf-browser 20:11:22 <mjg59> Package name probably ought to be surf-browser as well 20:11:23 <Kevin_Kofler> IIRC the problem is that there are plugins which use the binary name. 20:11:30 <cwickert> I suggest to rename the packge but not the binary 20:11:35 <pjones> well, they can't both use the same package name either; surf-browser for both the pkg and the binary is fine though 20:11:36 <dgilmore> Kevin_Kofler: they all need patching 20:11:47 <pjones> cwickert: and introduce a file conflict? 20:11:51 <cwickert> renaming the binary would cause work with the plugins 20:11:59 <cwickert> pjones, I don't think there is 20:12:08 <Kevin_Kofler> It really sucks that upstream refuses to rename. 20:12:13 <dgilmore> cwickert: it wouldnt be much work 20:12:22 <cwickert> pjones, I don't think there is a /usr/bin/surf 20:12:24 <dgilmore> and if done right should only need doing once 20:12:34 <cwickert> good point 20:13:17 <mjg59> The end of the bug commentary includes the packager requesting a package rename 20:13:19 <cwickert> how about waiting another week and investigating the other packages more detailled if there really is another surf binary 20:13:26 <abadger1999> pjones: ATM, file explicit Conflicts are very very highly discouraged (so things have to be renamed on the filesystem as well) 20:13:50 <pjones> abadger1999: well, they'd be implicit rather than explicit, but that's just as bad. 20:13:50 <dgilmore> i dont see any point in waiting. it seems the browser devs are going to be stuborn and resist any change 20:14:01 <abadger1999> pjones: Implicit is outright disallowed. 20:14:13 <pjones> abadger1999: that was my point, yes. 20:14:27 <pjones> but I don't have either package in front of me; is there actually a conflict introduced? 20:14:39 <mjg59> Kevin_Kofler: I'm not clear on the plugin issue. Do you mean they want to install in /usr/lib/surf/ ? 20:15:26 <cwickert> mjg59, AFAIK the plugins need to be patched to use /usr/bin/surf-browser then 20:16:01 <Kevin_Kofler> dgilmore: cwickert's point is that the other surf doesn't include a binary. 20:16:08 <cwickert> cassmodiah, you want to add something here? 20:16:17 <Kevin_Kofler> If that's true, then the surf browser binary does not need renaming. 20:16:32 <cwickert> but I'm not sure about this really 20:16:44 <Kevin_Kofler> Yes, this needs to be checked. 20:16:54 <Kevin_Kofler> I think the other surf is also an app, so it also has a binary. 20:16:55 <notting> if it's just the package name, that's easy. would anyone like to volunteer to check what would be required? 20:16:59 <mjg59> Kevin_Kofler: There's a surf.1 manpage 20:17:19 <cwickert> notting, I will try to figure this out with cassmodiah 20:17:39 <nirik> ok, so defer to next week? 20:17:40 <dgilmore> http://koji.fedoraproject.org/koji/rpminfo?rpmID=1772215 20:17:46 <dgilmore> there is a /usr/bin/durf 20:17:49 <dgilmore> surf 20:17:51 <mjg59> Ok. There's a surf binary. 20:18:02 <dgilmore> and a .desktop file 20:18:09 <pjones> okay, so the binary and the package need to be surf-browser, and the plugins need to be fixed to work with that. 20:18:13 <Kevin_Kofler> Right. 20:18:19 <pjones> (what on earth are they doing that needs to know the binary name?) 20:18:22 <dgilmore> so the new package needs to be surf-browser for name and binaries 20:18:36 <dgilmore> pjones: correct 20:18:51 <mjg59> Anyone disagree? 20:18:58 * dgilmore votes +1 to saying that it needs to be called surf-browser 20:19:31 <cwickert> I suggest to wait with renaming the binary until we figured out if there really are other surf binaries 20:19:44 * skvidal is +1 to renaming the browser anyway 20:19:56 <mjg59> cwickert: We figured it out. There are. 20:20:09 <cwickert> mjg59, in surf.sf.net? 20:20:12 <mjg59> cwickert: Yes 20:20:21 <cwickert> oh, i can't get it to compile 20:20:43 <cwickert> ok, then +1 for renaming to surf-browser for both binary and package 20:20:50 <Kevin_Kofler> +1 here too. 20:20:54 * nirik is ok with that. 20:21:07 <dgilmore> cwickert: http://koji.fedoraproject.org/koji/rpminfo?rpmID=1772215 20:21:13 * notting is +1 to that 20:21:17 <mjg59> +1 20:21:44 <nirik> #agreed surf package in Fedora should rename to surf-browser along with its binary and man pages, etc. 20:21:54 <nirik> #topic #320 Feature: Modprobe whitelist ( https://fedoraproject.org/wiki/Features/ModprobeWhitelist ) 20:21:54 <nirik> .fesco 320 20:21:55 <zodbot> nirik: #320 (Feature: Modprobe whitelist ( https://fedoraproject.org/wiki/Features/ModprobeWhitelist )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/320 20:22:15 <nirik> we were waiting here to see if upstream had responded about the patch/etc I think. 20:22:36 <nirik> mitr: any news here? 20:22:38 <pjones> mitr's been idle for 83 hours. 20:23:25 <Kevin_Kofler> It's listed as 90% complete now in any case. 20:23:31 <Kevin_Kofler> The code is ready. 20:23:37 <Kevin_Kofler> https://bugzilla.redhat.com/show_bug.cgi?id=560084 20:23:45 <pjones> yeah 20:23:47 <mjg59> The functionality sounds reasonable, so assuming it works I can't see any objection other than upstreamability 20:24:19 <pjones> upstream already agreed in concept, as I recall from last week, so I'm +1 on this. 20:24:32 <ajax> yeah, seems solid. +1. 20:24:38 <Kevin_Kofler> He sais in the Bugzilla the patches have been submitted upstream, but there's no link to the thread, so I can't verify. 20:24:42 <cwickert> too bad there is no response from the maintainer in the bug 20:24:49 <Kevin_Kofler> Nor check what upstream answered. 20:25:05 <pjones> the maintainer tends to be... laggy in response. 20:25:08 * nirik is +1 as well. Not sure how many people will use it, but it seems ok to have. 20:25:31 <pjones> but I think he'll say yes, really. 20:25:34 <cwickert> +1, as I tend to be paranoid ;) 20:25:39 * notting is +1 20:25:40 <Kevin_Kofler> I also vote +1 to this feature. I don't have any use for it myself, but I think paranoid admins are going to like i. :-) 20:25:47 <Kevin_Kofler> *like it 20:25:51 <pjones> that's 5 20:26:00 <nirik> #agreed Feature is approved. 20:26:03 <dgilmore> +1 though not sure how widely it will be adopted 20:26:11 <nirik> #topic #325 Fast-track Nonresponsive maintainer: Sindre Pedersen Bjørdal (sindrepb) 20:26:11 <nirik> .fesco 325 20:26:12 <zodbot> nirik: #325 (Fast-track Nonresponsive maintainer: Sindre Pedersen Bjørdal (sindrepb)) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/325 20:26:12 <pjones> dgilmore: don't really care ;) 20:26:20 <skvidal> +1 but, well, nevermind 20:26:38 <nirik> ok, I mailed them on the 19th. 20:26:48 <nirik> Others have mailed them since, with no reply that I know of. 20:27:17 <nirik> however: 20:27:25 <Kevin_Kofler> Oh joy, sindrepb owns 50 packages, they're all effectively orphaned, it seems. :-( 20:27:27 <nirik> I see a cvs lookaside upload from them today. 20:27:47 <nirik> but no commits or builds. 20:27:52 <Kevin_Kofler> Strange. 20:28:14 <skvidal> hmm 20:28:21 <cwickert> nirik, did he upload or was it just for one of his packages? 20:28:22 <skvidal> of the pkgs on my 'potentially unmaintained' list 20:28:28 <skvidal> sindrepb owns 25 20:28:32 <nirik> He is at university I understand, so he often gets busy... but... 20:28:52 <skvidal> http://fpaste.org/NpTL/ 20:28:59 <Kevin_Kofler> skvidal: https://admin.fedoraproject.org/pkgdb/users/packages/sindrepb?acls=owner lists 50 20:29:25 <skvidal> Kevin_Kofler: I am not disagreeing with you - I'm saying he has 25 pkgs on the 'questionably taken care of' list 20:29:35 <dgilmore> that also lists packages where you are a com-maintainer only 20:29:52 <Kevin_Kofler> With acls=owner? 20:30:00 <abadger1999> dgilmore: Kevin_Kofler is doing it right. That only lists strict owners. 20:30:00 <pjones> so it sounds like the thing to do is find him some co-maintainers. 20:30:03 <skvidal> Kevin_Kofler: I';m not disagreeing! :) 20:30:13 <skvidal> Kevin_Kofler: he owns 50 pkgs 20:30:24 <skvidal> 25 of those have not been built by a non-automated process in over a year 20:30:36 <nirik> weird. So I see that in my mailbox, but not in the scm-commits archive? wtf? 20:30:38 <Kevin_Kofler> We really need somebody to take care of the recordmydesktop stack, I think a lot of people use it. 20:30:59 <Kevin_Kofler> I could pick it up if nobody else wants it, but I don't use it myself. 20:31:04 <nirik> oh, it's going to the old list. 20:31:20 <Kevin_Kofler> But I guess that's more a discussion for the devel ML. 20:31:32 <nirik> https://www.redhat.com/archives/fedora-extras-commits/2010-January/msg00188.html 20:31:48 <pjones> skvidal: not a very good heuristic/ 20:32:01 <notting> i think it's a fair statement that this guy appears to be inactive, though. 20:32:04 <skvidal> pjones: sigh - we discussed this 2 weeks ago in irc 20:32:05 <pjones> yes 20:32:25 <skvidal> pjones: http://skvidal.fedorapeople.org/misc/potentially-unmaintained/ 20:32:37 <skvidal> pjones: the point is to find potential problems. 20:32:48 <nirik> notting: except for the weird upload today... 20:34:08 <Kevin_Kofler> I'd inspect that upload very closely, it might actually be an intruder abusing the account. 20:34:14 <nirik> so, a) orphan all their packages, b) wait further and see if the upload today is showing renewed activity c) something else? 20:34:16 <pjones> anyway, as I said a while back, it sounds like the thing to do is find him some co-maintainers. 20:35:23 <nirik> well, we could ask for co-maintainers and approve them if anyone asks on those packages. Would be a manual step to ask to get approved tho. 20:36:09 <notting> Kevin_Kofler: it matches upstream. *shrug* 20:36:34 <cwickert> maybe has has just problems with his cvs access? 20:36:36 <Kevin_Kofler> OK, so I guess it's fine. 20:36:39 <nirik> sorry, thats a month ago. I am blind. ;) 20:36:52 <pjones> I don't like the idea of saying 4 months away is entirely missing (I know of companies where employees regularly take 6-month sabbaticals,...), but at the same time, he should have told everybody if it's a case like that (did he?), and there should be somebody else maintaining the packages. 20:36:55 <dgilmore> nirik: your not in Australia :) 20:37:03 <Kevin_Kofler> And sources wasn't updated to include that file since?! 20:37:31 <Kevin_Kofler> There may be some technical issues indeed. 20:38:26 * notting votes +1 to 'yes, he's inactive, please continue the process' 20:38:35 <dgilmore> +1 from me also 20:38:41 <cwickert> +1 20:38:41 <pjones> he's clearly AWOL, so yeah, +1 20:38:43 <ajax> +1 20:38:56 <skvidal> +1 20:39:10 <nirik> ok, +1 here too... 20:39:10 <cwickert> someone should write a mail to fedora-devel with the list of packages 20:39:14 <mjg59> +1 20:39:28 <nirik> who would like to do that? ;) 20:39:35 <cwickert> I can do it 20:39:40 <pjones> cwickert sounded like he was volunteering 20:39:40 <pjones> ;) 20:39:45 <cwickert> :P 20:39:51 <nirik> we should orphan them all before posting, so people can take them when they see that email, right? 20:39:59 <cwickert> right 20:39:59 <Kevin_Kofler> Yeah, +1 to considering sindrepb non-responsive. 20:40:43 <nirik> #agreed Maintainer is unresponsive, will find (co)maintainers for his packages. 20:40:59 <nirik> #topic #327 Feature: StorageFiltering ( https://fedoraproject.org/wiki/Anaconda/Features/StorageFiltering ) 20:40:59 <nirik> .fesco 327 20:41:02 <zodbot> nirik: #327 (Feature: StorageFiltering ( https://fedoraproject.org/wiki/Anaconda/Features/StorageFiltering )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/327 20:41:17 <pjones> Since this is largely a completed project, I'm +1 on it. 20:41:50 <nirik> yeah, +1 to improving filtering here. 20:41:54 * notting is +1 20:41:55 * skvidal is +1 20:42:04 <cwickert> +1 20:42:11 <ajax> +1 20:42:27 <nirik> #agreed Feature is approved. 20:42:45 <nirik> #topic #328 Feature: Dogtag Certificate System ( https://fedoraproject.org/wiki/Features/DogtagCertificateSystem ) 20:42:45 <nirik> .fesco 328 20:42:48 <zodbot> nirik: #328 (Feature: Dogtag Certificate System ( https://fedoraproject.org/wiki/Features/DogtagCertificateSystem )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/328 20:43:01 <dgilmore> +1 to storage 20:43:07 <dgilmore> and +1 to dogtag 20:43:18 <notting> +1 to dogtag 20:43:24 * dgilmore thinks dogtag in fedora is long overdue 20:43:31 <cwickert> yeah 20:43:32 <pjones> +1 20:43:36 <cwickert> +1 of course 20:43:38 <ajax> yes plz. +1 20:43:41 <skvidal> +1 20:43:56 <nirik> +1 here too. Seems like a nice system to have and I know they have worked hard on packaging it. 20:43:59 <Kevin_Kofler> +1 to dogtag 20:44:05 <nirik> #agreed Feature is approved. 20:44:14 <nirik> #topic #329 Feature: KVM Stable PCI addresses ( https://fedoraproject.org/wiki/Features/KVM_Stable_PCI_Addresses ) 20:44:14 <nirik> .fesco 329 20:44:15 <Kevin_Kofler> (and for the record, also another +1 to the Anaconda storage stuff, not that it matters) 20:44:16 <zodbot> nirik: #329 (Feature: KVM Stable PCI addresses ( https://fedoraproject.org/wiki/Features/KVM_Stable_PCI_Addresses )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/329 20:44:52 <pjones> I'm still +1 on this. 20:44:53 <mjg59> Seems sane, and also has the benefit of having been written 20:45:00 <ajax> approve. 20:45:08 <notting> sure, +1 20:45:09 <mjg59> So, +1 to feature approval 20:45:15 <skvidal> +1 20:45:20 <cwickert> +1 20:45:35 <nirik> +1 here as well. 20:46:14 <nirik> #agreed Feature is approved. 20:46:22 <nirik> #topic #330 Feature: Multipath install ( https://fedoraproject.org/wiki/Features/MultipathInstall ) 20:46:23 <nirik> .fesco 330 20:46:24 <zodbot> nirik: #330 (Feature: Multipath install ( https://fedoraproject.org/wiki/Features/MultipathInstall )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/330 20:46:27 * dgilmore ready doesnt care but i see no harm 20:46:29 <pjones> Obviously, I'm +1 on this. 20:46:40 <mjg59> Again, +1 20:46:47 <Kevin_Kofler> Re stable PCI addresses: Ugh, the joys of making broken proprietary OSes happy. :-/ 20:46:50 <skvidal> +1 20:46:53 * dgilmore needs storage to test this one 20:47:01 <ajax> +1. lul-tee-path. 20:47:09 <pjones> Kevin_Kofler: Re that, it's really more like "make virt act like real hardware" 20:47:28 * dgilmore is +1 fpr multipath 20:47:35 <nirik> I'm not sure how many fedora folks will use multipath, but good to have... +1 here. 20:47:38 <Kevin_Kofler> +1 to MultipathInstall 20:47:57 <nirik> #agreed Feature is approved. 20:47:58 <notting> ACK to multipath 20:48:08 <nirik> #topic #331 Feature: NetworkManager MobileStatus ( https://fedoraproject.org/wiki/Features/NetworkManagerMobileStatus ) 20:48:08 <nirik> .fesco 331 20:48:14 * pjones wonders if he shouldn't have voted against multipath ;) 20:48:15 <zodbot> nirik: #331 (Feature: NetworkManager MobileStatus ( https://fedoraproject.org/wiki/Features/NetworkManagerMobileStatus )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/331 20:48:35 * nirik is sad here that his card isn't supported for this one. ;( 20:49:08 <notting> ACK, seems incremental and isolated 20:49:12 <pjones> +1 on this 20:49:13 <ajax> +1 to mobile status. 20:49:15 <mjg59> +1 20:49:22 <skvidal> +1 20:49:23 <nirik> yeah, +1 in any case, good to have. 20:49:26 <cwickert> +1 20:49:27 <dgilmore> +1 20:49:31 <nirik> #agreed Feature is approved. 20:49:39 <nirik> #topic #332 Feature: Virtx2apic ( https://fedoraproject.org/wiki/Features/Virtx2apic ) 20:49:39 <nirik> .fesco 332 20:49:46 <zodbot> nirik: #332 (Feature: Virtx2apic ( https://fedoraproject.org/wiki/Features/Virtx2apic )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/332 20:50:01 <ajax> yay, virt performance. +1. 20:50:19 <pjones> +1 20:50:29 <pjones> it's isolated and transparent, so why the hell not 20:50:32 <nirik> is this landed in 33 kernels? or ? 20:50:35 <notting> ack, although i'd love to know how noticeable the performance is 20:50:36 <Kevin_Kofler> +2 to x2apic 20:50:43 <Kevin_Kofler> Argh… 20:50:46 <Kevin_Kofler> +1 to x2apic 20:50:53 <Kevin_Kofler> Sorry, I hit the wrong number key. ;-) 20:50:59 <cwickert> whatever makes vvirtualization faster gets +1 from me 20:51:07 <mjg59> Sure, +1 20:51:09 <nirik> +1 here, faster is more better. 20:51:39 <nirik> #agreed Feature is approved. 20:51:47 <nirik> #topic #333 Feature: VHostNet ( https://fedoraproject.org/wiki/Features/VHostNet ) 20:51:48 <nirik> .fesco 333 20:51:50 <zodbot> nirik: #333 (Feature: VHostNet ( https://fedoraproject.org/wiki/Features/VHostNet )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/333 20:52:05 <dgilmore> +1 to x2apic 20:52:30 <mjg59> +1 to VHostNet 20:52:42 <dgilmore> +1 to vhostnet though its kinda porly named 20:52:44 <nirik> I think vhostnet needs updates on docs and release notes. 20:53:01 <mjg59> But it would be nice to have all the virtualisation notes tided up into a similar format, which I guess can be done as aprt of the editing process 20:53:04 <nirik> The tests seem vuage to me as well. 20:53:06 <notting> +1 with nirik's caveat 20:53:15 <pjones> I'm with nirik here - I'd like an updated status since we're reading the page that claims it's from july 20:53:16 * dgilmore thought it was for setting up network bridges on the host for virtual gues by the name 20:53:19 <pjones> (but I like it) 20:53:22 <Kevin_Kofler> +1, but docs and release notes should be filled in 20:53:47 <ajax> yeah, not the best feature name, updates would be appreciated. +1 otherwise. 20:54:10 <nirik> ok, I'm +1 as long as the page can get updated... 20:54:25 <cwickert> +1, but updates to the release notes are needed 20:54:44 <nirik> #agreed Feature is approved. 20:55:01 <jforbes> nirik: will get updates applied to the vhostnet page 20:55:10 <nirik> jforbes: thanks! 20:55:29 <nirik> ok, next we have 2 features that were moved to readyforfesco after the deadline... 20:55:33 <nirik> #topic #334 Late Feature Exception: NetworkManager Cmdline ( https://fedoraproject.org/wiki/Features/NetworkManagerCmdline ) 20:55:33 <nirik> .fesco 334 20:55:35 <zodbot> nirik: #334 (Late Feature Exception: NetworkManager Cmdline ( https://fedoraproject.org/wiki/Features/NetworkManagerCmdline )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/334 20:55:53 <dgilmore> jforbes: please consider enaming to someing like ParaVirtGuestNetworking 20:56:16 <ajax> again, kinda wish it weren't named nmcli 20:56:24 <jforbes> dgilmore: I will pass it on 20:56:30 <ajax> although nm-tool is already taken, for something far more useless 20:56:35 <notting> ajax: prod dcbw? he may be amenable to renaming it 20:56:37 <nirik> ajax: yeah. ;( 20:56:44 <mjg59> Other than the name, it's functionality that people have been asking for, so +1 20:56:51 <ajax> but omg yes totally want this. 20:56:52 <ajax> +1 20:56:58 * notting has been sending some review notes to them 20:56:59 <ajax> notting: will do. 20:57:04 <cwickert> +1 bzut the name could be better 20:57:06 <notting> +1 20:57:10 <cwickert> nm-command or something 20:57:10 <pjones> +1 but yes. 20:57:13 * dgilmore is +1 fro nmcli 20:57:16 <ajax> nmctl even 20:57:21 <pjones> nmctl would be good. 20:57:28 <ajax> yay, i painted the shed. 20:57:34 <Kevin_Kofler> +1 to the NM CLI feature 20:57:47 <nirik> +1 to green 20:57:54 <nirik> er, I mean this feature. ;) 20:58:02 <cwickert> i think it should nm-something with dash for consistency, but anyway... 20:58:11 <nirik> #agreed Feature is approved. 20:58:24 <nirik> #topic #335 Late Feature Exception: NetworkManager Bluetooth DUN ( https://fedoraproject.org/wiki/Features/NetworkManagerBluetoothDUN ) 20:58:25 <nirik> .fesco 335 20:58:27 <zodbot> nirik: #335 (Late Feature Exception: NetworkManager Bluetooth DUN ( https://fedoraproject.org/wiki/Features/NetworkManagerBluetoothDUN )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/335 20:58:39 <notting> +1 20:58:46 <skvidal> +1 20:58:49 <skvidal> it's more or less done 20:59:02 <nirik> yeah, +1... I see people asking for this a fair bit. 20:59:04 <ajax> +1 20:59:05 <mjg59> +1 20:59:23 <dgilmore> +1 20:59:50 <nirik> #agreed Feature is approved. 21:00:01 <nirik> #topic Open Floor 21:00:07 <skvidal> potentially unmaintained 21:00:08 <nirik> ok, any items for open floor? 21:00:13 <Kevin_Kofler> Sadly seems to be GNOME-only, like also that NM mobile status feature. :-( 21:00:34 <cwickert> somebody asked me if FESCO could open their mailing list achives 21:00:40 <skvidal> so I wanted to ask if anyone had any thoughts/comments on the potentially unmaintained checking that I mentioned before 21:00:45 <nirik> #topic Potentially Unmaintained script 21:00:48 <skvidal> (about 2 weeks ago) 21:00:54 <skvidal> on the fesco list 21:00:59 <nirik> lets do this first, then cwickert's item? 21:01:07 <mjg59> Kevin_Kofler: Patches would be, I suspect, absolutely welcome 21:01:09 <cwickert> first skvidal I think 21:01:10 * dgilmore likes it 21:01:15 <skvidal> it's just to get us an idea of pkgs/folks that we should be looking at closer 21:01:55 <skvidal> my big plan was once a release cycle, run it and see what turns up. Take that list and ask the maintainers to say 'yay or nay' to whether they are still involved/maintaining it 21:01:56 <Kevin_Kofler> I'm sure there are plenty of false positives. 21:01:56 <nirik> skvidal: so, this is focusing on packages right? so packages that seem like they might be not maintained... 21:02:22 <skvidal> Kevin_Kofler: which is why we aren't taking any serious action 21:02:26 <skvidal> nirik: yes 21:02:28 <Kevin_Kofler> I have some packages which I haven't updated since "forever" because there was no upstream release and no bug report, so what would I have updated them for? 21:02:50 <pjones> skvidal: I think it seems more likely to be finding packages with dead upstreams than packages that are actually unmaintained themselves. 21:03:06 <cwickert> sorry if this a dump question. why are unmaintained packages bad? We have packages that are dead upstream but still serve their purpose pretty well 21:03:08 <skvidal> Kevin_Kofler: and then that would mean we would send you a note once a release to confirm that you are still involved 21:03:19 <skvidal> cwickert: it depends on WHY they are unmaintained 21:03:25 <pjones> (dead or near-dead. I see that ajax owning powertop is on the list, as is my python-goopy, both of which are like that) 21:03:29 <skvidal> if they are unchanging b/c nothing is changing - that's fine 21:03:43 <skvidal> and not a big deal to the maintainer to say 'yep' to 21:03:46 * nirik has driconf on the list... it's just had no love at all upstream in forever. 21:03:58 <skvidal> if they are unchanging b/c they are abandoned by the packager - that's not fine 21:04:10 <dgilmore> having something to go by to make sure someone is around to look after a package should it be needed is important 21:04:24 <dgilmore> pjones: but you have other things actively maintained 21:04:26 <skvidal> and to be fair - if the pkg is abandoned upstream - I'm happy with reminding the packager about this 21:04:39 * nirik likes the idea of this... also will give a chance for maintainers to reflect once a release: "should I keep shipping this thing" 21:04:40 <skvidal> so they can evaluate whether or not the pkg is a benefit to be in fedora 21:04:47 <cwickert> skvidal, for example gnome-ppp is a wvdail frontend. as long as there are no big changes in gtk, there is no maintainance needed. and it's still in the top 10 of the most popular apps at gnomefliles.org 21:04:50 <pjones> skvidal: fair enough 21:04:53 <skvidal> and remember 21:04:54 <pjones> python-goopy certainly isn't 21:05:00 <skvidal> this is not a punitive mechanism 21:05:10 <skvidal> it's just a reminder 21:05:27 <skvidal> hell - when I published the first list to #fedora-devel rdieter found 2 pkgs he had forgottenabout and needed to orphan 21:05:43 * rdieter yays 21:05:48 * nirik will likely orphan/drop some of the ones he has on the list. 21:05:49 <skvidal> and I'd like to be able to add extra info from git to that data 21:06:00 * cwickert likes the idea if it is a friendly reminder for maintainers. if it is something for AWOL or so, then I'd say no 21:06:06 <skvidal> not awol 21:06:11 <cwickert> ok then 21:06:13 <skvidal> but I will be honest 21:06:18 <skvidal> if we say "hey are you maintaining this" 21:06:21 <skvidal> and no one responds 21:06:24 <skvidal> AT ALL 21:06:28 <pjones> yeah, I think that's generally fine 21:06:31 <skvidal> that says to me they're not reading their email 21:06:42 <cwickert> fair enough, I found a package on your list I totally forgot 21:06:50 <pjones> I'm just concerned that this is going to wind up being another cron job that mails everybody with little or no reason 21:07:08 <skvidal> pjones: which is why I'd like to expand the checks 21:07:08 * nirik wonders how much screaming he will get from finally dropping gdk-pixbuf. 21:07:24 <skvidal> beyond just the builds - to checkins as well 21:07:38 <skvidal> so we are notifying fewer people 21:08:18 <skvidal> so my question is this - does anyone have any problem with my pursuing this further? 21:08:33 <skvidal> I'll probably bring it back to fesco officially to get it enabled after f13 is released 21:08:34 * cwickert hasn't 21:08:35 * nirik does not. jfdi. ;) 21:08:55 <pjones> skvidal: go for it 21:08:59 <cwickert> skvidal, what is your plan exactly? reminders by mail? 21:08:59 <dgilmore> skvidal: please pursure it further 21:09:09 <ajax> yeah, i'm for pursuing this. 21:09:10 <skvidal> cwickert: maybe - or tying it into pkgdb 21:09:23 <skvidal> cwickert: so you can go to a webpage and click 'yep, I maintain this' 21:09:25 <cwickert> ether way, it should be public to all packages 21:09:35 <cwickert> s/packages/packagers 21:09:36 <skvidal> cwickert: 'public to all packages'? 21:09:37 <skvidal> oh 21:09:39 <skvidal> packagers 21:09:40 <skvidal> sure 21:09:40 <pjones> cwickert: oh please no 21:10:03 <skvidal> cwickert: but I don't want it seen as a shaming mechanism 21:10:06 <skvidal> cwickert: is that what you mean? 21:10:07 <pjones> we don't need more mail to f-d-l where you need to search for your name in the body to see if it effects you. 21:10:10 <pjones> that stuff sucks. 21:10:32 <cwickert> skvidal, well, if someone decides to orphan foo i might consider taking it over 21:10:39 <pjones> (it's only slightly better than the stuff where you've got to remember all the packages you maintain and search for each of them in the body...) 21:10:43 <Kevin_Kofler> I think having to repeatedly confirm "yes, I'm still alive" is quite annoying. 21:10:59 <nirik> pjones: private single email better? 21:11:06 <pjones> nirik: yes 21:11:25 <pjones> I might suggest that on N-months of not-having-been rebuilt, send a mail. 21:11:40 <pjones> where N is all of, say, 6,12,18,24,32, etc. 21:11:41 <cwickert> pjones, post a full list to f-d-l and a personalized list to the maintainers in question 21:11:49 <nirik> cwickert: this script won't orphan anything itself, it will just produce a list of 'these people did not respond to say they were still maintinging these packages' 21:11:55 <skvidal> we'll talk about this further after I'm ready 21:11:56 <pjones> cwickert: I guess, but I still think most people read such posts to f-d-l with the 'd' key. 21:12:01 <skvidal> but for now I'll continue working on it 21:12:02 <nirik> cwickert: so it would then be up to us to look at the list and decide to orphan them... 21:12:14 <cwickert> i know nirik 21:12:15 <skvidal> thank you for the time, folks 21:12:23 <nirik> ok, anything more on this topic? 21:12:29 <cwickert> go for it 21:12:39 <nirik> #topc fesco mailing list archives 21:12:51 <nirik> #topic fesco mailing list archives 21:12:55 <nirik> cwickert: ? 21:13:24 <cwickert> last week I asked FAMSO to open their trac for all ambassadors. one famsco member replied that we had a closed mailing list archive 21:13:50 * nirik nods. 21:13:57 <cwickert> I don't thing there is a connection between both, but can we make the archives public? 21:14:00 <mjg59> I'm semi-uncomfortable with the opening of archives that were previously understood to be closed 21:14:06 <skvidal> mjg59: agreed 21:14:14 <mjg59> I'd be absolutely happy with it being open going forward 21:14:14 <skvidal> mjg59: now, if we want to make NEW archives 21:14:18 <skvidal> nod 21:14:42 <nirik> we have had people mail sensitive things to the fesco list in the past, or things they didn't want released publicly (yet) 21:15:03 <nirik> mostly it's scheduling junk and tickets, which should be no problem to open. 21:15:10 <cwickert> right 21:15:17 <mjg59> The trac stuff is all public anyway? 21:15:26 <cwickert> it is 21:15:27 <Kevin_Kofler> There's at least one security-sensitive thread on the FESCo ML. 21:15:47 <cwickert> and i doubt that there is anything confidential in FAMSCOs trac, but they don't like opening it 21:16:16 <cwickert> Kevin_Kofler, good point 21:16:23 <skvidal> security sensitive is a bit of a concern 21:16:28 <dgilmore> cwickert: there are a few lists with closed archives that should probbaly be opened 21:16:50 <skvidal> notting: who gets vendor-sec for fedora? 21:16:54 <dgilmore> there are some that are hidden and probably should not be hidden 21:16:57 <cwickert> dgilmore, ok, so should we discuss this in a wider context? 21:16:59 <dgilmore> skvidal: no one 21:17:04 <notting> skvidal: don't know, possibly nobody 21:17:17 <notting> skvidal: i suspect the RH secalert team prods people where necessary 21:17:20 <mjg59> So I don't think there's a good argument for opening past archives, given that the vast majority of the content is already public and we'd have to audit the rest 21:17:21 <pjones> I bet mcox does 21:17:29 <dgilmore> skvidal: last i knew we had no relationship there 21:17:30 <nirik> mjg59: I agree. 21:18:00 <mjg59> But if we can clearly message that the fesco list won't be private in future, I think there's no especially good reason for it to be closed 21:18:07 <ajax> what he said. 21:18:15 <mjg59> The only proviso to that is that if there /is/ anything sensitive, it'll then ahve to be emailed to individuals 21:18:21 <mjg59> Which means there's less of a paper trail in future 21:18:26 <nirik> mjg59: right, which makes it harder... 21:18:44 <ajax> presumably if we need that in the future we can get a fesco-private@ 21:19:05 <cwickert> honestly, i cannot decide on that, I think long term fesco members know better than me 21:19:32 * skvidal is in favor of fesco-private/fesco-closed created 21:19:38 <skvidal> and all but ugly stuff goes to fesco 21:19:44 <mjg59> Works for me 21:19:49 <pjones> I think that's... impractical 21:19:56 * nirik worried that if we open things we will get someone mailing the public list when they thought it was private tho. 21:20:08 <dgilmore> skvidal: going to a board like model is ok i think 21:20:17 <pjones> or rather, I don't think there's enough visibility that we can expect people who need things to be private to realize that there's a separate list for that. 21:20:29 <nirik> on the other hand, the number of sensitive emails over the years has been very small. 21:20:30 <dgilmore> I do belive that there should be a way for someone to bring a confidentail issue to FESCo 21:20:44 <pjones> tbf, there's an entirely separate address for security stuff 21:20:58 <skvidal> pjones: doesn't have to be just security 21:21:00 <dgilmore> pjones: its usually not security related 21:21:04 <nirik> dgilmore: does trac have any kind of 'private ticket' thing? 21:21:19 <dgilmore> nirik: possibly im not 100% sure 21:21:27 <skvidal> pjones: personal problems, for example, could be included 21:21:32 <pjones> skvidal: true enough 21:21:44 <pjones> okay, fesco-private seems reasonable enough for that 21:22:31 <nirik> as long as people know to use it instead of the regular one. ;) 21:22:39 <Kevin_Kofler> Well, IMHO non-confidential stuff should just go through Trac. 21:23:07 <cwickert> nirik, you can make tickets private for just the submitter and people of a certain fas group, but I don't think it is possible to change that for individual tickets 21:23:30 <cwickert> it applies to the complete trac instance I think 21:24:05 <nirik> so: make new fesco-private list, copy subscribers from fesco to it, current archives moved to fesco-private, new archives on fesco open? 21:24:11 * abadger1999 notes that all non-private fesco stuff was supposed to go to devel list 21:24:26 <notting> abadger1999: and it normally does 21:24:32 <nirik> abadger1999: yeah, does. 21:24:42 <nirik> I suspect a fesco-private list will get no posts. 21:25:00 <abadger1999> fesco was a mail alias specifically for stuff inappropriate for public consumption. 21:25:07 <cwickert> the less private mails the better 21:25:27 <nirik> abadger1999: it's an easy way to mail trac info to fesco members... 21:25:31 <abadger1999> Then it was turned into a mailing list so we'd have archives of the private messages if need be. 21:26:23 <dgilmore> abadger1999: right and really all it gets is trac mail 21:26:26 <nirik> right, so the amount of non trac stuff on the fesco list is near 0 21:26:27 * abadger1999 finishes reporting the history of the fesco alias/mailing list. 21:26:40 <Kevin_Kofler> I don't really see what we need a public list for. People should just use the Trac system! 21:27:00 <Kevin_Kofler> (And they mostly do, anyway.) 21:27:31 <nirik> right. 21:28:11 <nirik> so, perhaps we should just say all our public business is in trac, and the mailing list is non public things, and move on? 21:28:50 <skvidal> that would keep us from having to move the old archives along 21:29:17 <Kevin_Kofler> nirik: +1 21:29:19 <pjones> that sounds fine 21:29:45 <mjg59> Sure 21:29:47 <mjg59> +1 to that 21:29:55 <notting> nirik: +1. i'm sure someone will pop up with a conspiracy theory, but.. .meh. 21:30:22 <cwickert> +-0, I'm still new to FESCO 21:30:24 <nirik> they could still come up with one I am sure... ;) 21:30:25 <ajax> wfm. +1. 21:30:31 <skvidal> +1 21:30:45 <nirik> cwickert: feel free to read back to the archives... not much there really. 21:30:46 <dgilmore> +! 21:30:48 <dgilmore> +1 21:31:43 <nirik> #agreed The fesco list is for nonpublic/sensitive matters. Use trac for public issues. Use of the private list will be kept to a minimum. 21:31:54 <nirik> #topic Open Floor 2: the return 21:32:01 <nirik> Any other further open floor items? 21:33:11 * nirik will close this meeting in a minute if nothing else comes along. 21:33:12 <cwickert> one more question.... 21:33:18 <nirik> shoot... 21:33:19 <cwickert> the new accounts dialog 21:33:37 <cwickert> it was approved already back in F12 21:33:59 <cwickert> it it replaces system-config-users, what about managing groups 21:34:13 <cwickert> and what about other display managers such as kdm or slim? 21:34:26 <cwickert> was this considered back when it was discussed? 21:34:28 <Kevin_Kofler> AFAIK system-config-users is not going away. 21:34:39 <cwickert> according to the feature page it is 21:34:53 * nirik thought it was staying around too. 21:35:01 <Kevin_Kofler> I asked and they said the package would be there, just no longer shipped on the GNOME spin. 21:35:10 <drago01> well it might not be installed by default on the desktop spin 21:35:17 <drago01> but I doubt it obsoletes it 21:35:18 <cwickert> ah, ok then 21:35:18 <Kevin_Kofler> FWIW, for KDE, there's kuser in kdeadmin which can be used instead. 21:35:26 <Kevin_Kofler> We don't need system-config-users for KDE anyway. 21:35:38 <Kevin_Kofler> But XFCE and LXDE may want system-config-users. 21:35:46 <cwickert> i see. as long as s-c-u is still around, I'm happy 21:35:50 <cwickert> EOF 21:36:04 * nirik will close this meeting in a minute if nothing else comes along. 21:36:25 <nirik> Thanks for coming everyone! 21:36:38 <nirik> #endmeeting
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
