Minutes/Summary for 2010-02-02 FESCo meeting
Kevin Fenzi
kevin at scrye.com
Tue Feb 2 21:37:26 UTC 2010
===================================
#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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100202/c0ac8039/attachment-0001.bin
More information about the devel
mailing list