Summary/Minutes from today's FESCo meeting (2011-11-14 at 18UTC)

Mon Nov 14 19:39:57 UTC 2011

===================================
#fedora-meeting: FESCO (2011-11-14)
===================================

Meeting started by nirik at 18:00:01 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2011-11-14/fesco.2011-11-14-18.00.log.html

Meeting summary
---------------
* init process  (nirik, 18:00:01)

* #667 Request to fix CRITPATH update process  (nirik, 18:02:21)
  * will defer this for a week looking for more input from QA/Tester
    folks.  (nirik, 18:03:41)
  * AGREED: will defer this for a week looking for more input from
    QA/Tester folks.  (nirik, 18:03:53)

* #692 Adjust FESCo election policy  (nirik, 18:04:00)
  * ACTION: defer to next week, collect feedback and revisit.  (nirik,
    18:19:36)

* #690 F17 Feature: move all to /usr
  https://fedoraproject.org/wiki/Features/UsrMove  (nirik, 18:19:50)
  * ACTION: : -4 votes, +4 votes, feature owners will consult with
    remaining fesco member in ticket.  (nirik, 18:41:38)
  * ACTION: nirik to file FPC ticket for looking over things vs
    guidelines.  (nirik, 18:41:55)

* #693 IPv6 support requirement in Fedora package  (nirik, 18:43:09)
  * AGREED: tell maintainer to please support listening on both ipv4 and
    ipv6 in vsftpd. additionally, file FPC ticket to ask them to add a
    'SHOULD: should support both ipv6 and ipv4 connections if support
    exists' ?  (nirik, 18:54:15)
  * ACTION: nirik to file FPC ticket about ipv6 support.  (nirik,
    18:59:14)

* #694 Consider sanctions against glibc  (nirik, 19:00:12)
  * AGREED: remove ownership/acls for current glibc maintainer on the
    glibc package.  (nirik, 19:10:39)
  * LINK:
    https://admin.fedoraproject.org/pkgdb/users/packages/schwab?acls=owner&acls=approveacls&acls=commit
    (abadger1999, 19:12:06)

* #695 Recommend 64-bit download by default  (nirik, 19:12:53)
  * LINK:
    http://lists.fedoraproject.org/pipermail/advisory-board/2011-November/011037.html
    (nirik, 19:17:05)
  * LINK:
    http://lists.fedoraproject.org/pipermail/advisory-board/2011-November/011037.html
    (abadger1999, 19:17:19)
  * AGREED: will promote 64bit as default for f17. websites to determine
    the best way to present things.  (nirik, 19:23:52)

* #696 F17 Feature: Gnome Shell Configurability
  https://fedoraproject.org/wiki/Features/GnomeShellConfigurability
  (nirik, 19:24:30)
  * AGREED: Feature is rejected at this time. Feature owner should work
    with desktop team/gnome upstream.  (nirik, 19:27:31)

* #697 F17 Feature - ConsoleKit Removal/Automatic Multi-Seat Support -
  https://fedoraproject.org/wiki/Features/ckremoval None  (nirik,
  19:27:35)
  * AGREED: Feature is approved.  (nirik, 19:29:45)

* #698 F17Feature: SysV to Systemd -
  https://fedoraproject.org/wiki/Features/SysVtoSystemd  (nirik,
  19:30:17)
  * AGREED: Feature is approved.  (nirik, 19:31:29)

* Consider including bash-completion package by default (base, not core)
  (nirik, 19:31:33)
  * AGREED: Feature is approved.  (nirik, 19:32:37)

* Open Floor  (nirik, 19:32:56)
  * ACTION: mjg59 to chair next week.  (nirik, 19:37:19)

Meeting ended at 19:39:11 UTC.

Action Items
------------
* defer to next week, collect feedback and revisit.
* : -4 votes, +4 votes, feature owners will consult with remaining fesco
  member in ticket.
* nirik to file FPC ticket for looking over things vs guidelines.
* nirik to file FPC ticket about ipv6 support.
* mjg59 to chair next week.

Action Items, by person
-----------------------
* mjg59
  * mjg59 to chair next week.
* nirik
  * nirik to file FPC ticket for looking over things vs guidelines.
  * nirik to file FPC ticket about ipv6 support.
* **UNASSIGNED**
  * defer to next week, collect feedback and revisit.
  * : -4 votes, +4 votes, feature owners will consult with remaining
    fesco member in ticket.

People Present (lines said)
---------------------------
* nirik (165)
* ajax (51)
* t8m (47)
* mjg59 (47)
* abadger1999 (37)
* sgallagh (30)
* dwmw2 (26)
* pjones (25)
* haraldh (21)
* drago01 (19)
* mmaslano (17)
* zodbot (14)
* jsmith (13)
* kay (9)
* Southern_Gentlem (9)
* gholms (5)
* cwickert (5)
* lmacken (2)
* skalnik_rh (2)
* shaiton (2)
* bpepple (1)
* Viking-Ice (1)
* adamw (1)
* jwb (1)
* notting (0)
--
18:00:01 <nirik> #startmeeting FESCO (2011-11-14)
18:00:01 <zodbot> Meeting started Mon Nov 14 18:00:01 2011 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:01 <nirik> #meetingname fesco
18:00:01 <zodbot> The meeting name has been set to 'fesco'
18:00:01 <nirik> #chair notting nirik ajax cwickert mjg59 mmaslano t8m pjones sgallagh
18:00:01 <nirik> #topic init process
18:00:01 <zodbot> Current chairs: ajax cwickert mjg59 mmaslano nirik notting pjones sgallagh t8m
18:00:19 <t8m> Hello
18:00:30 <nirik> morning all.
18:01:01 <sgallagh> I'm here but splitting my attention
18:01:16 <mmaslano> hi
18:01:32 * cwickert is here but needs to leave later
18:01:43 * ajax waves
18:01:50 * jsmith lurks
18:01:52 <mjg59> Hi
18:01:53 <nirik> notting will be unable to attend today, but has voted in many tickets.
18:02:02 * abadger1999 lurks
18:02:09 <nirik> we have a pretty full docket, so, lets go ahead and dive in.
18:02:21 <nirik> #topic #667 Request to fix CRITPATH update process
18:02:22 <nirik> .fesco 667
18:02:23 <zodbot> nirik: #667 (Request to fix CRITPATH update process) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/667
18:02:33 <nirik> so, I don't think we got much QA feedback on this last week...
18:02:45 <nirik> proposal: defer another week for more feedback
18:02:55 <ajax> aye
18:03:00 <mmaslano> fine by me
18:03:06 <mjg59> Sure
18:03:16 <t8m> nirik, given the amount of topics for today, I am OK with defering
18:03:25 <nirik> ok.
18:03:41 <nirik> #info will defer this for a week looking for more input from QA/Tester folks.
18:03:53 <nirik> #agreed will defer this for a week looking for more input from QA/Tester folks.
18:04:00 <nirik> #topic #692 Adjust FESCo election policy
18:04:01 <nirik> .fesco 692
18:04:03 <zodbot> nirik: #692 (Adjust FESCo election policy) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/692
18:04:15 <nirik> we talked about this last week, but didn't come to any conclusion.
18:04:42 <mjg59> I've brought it up on list. Sorry for taking so long to do so.
18:04:47 <pjones> I am here.
18:04:53 * nirik is happy to have qa folks able to be in fesco, but there's not any easy way to do it off hand...
18:04:56 <mjg59> We may want to wait to see if there's more feedback
18:05:16 <t8m> I agree, there is no hurry now.
18:05:33 <cwickert> notting suggested "some combination of packager, qa, proventester, rel-eng"
18:05:33 <pjones> yeah, there's no deadline on this so we can wait for more feedback with no issue.
18:05:50 * nirik notes again the 'qa' group is not used.
18:05:52 <t8m> qa and releng are already packager
18:06:04 <t8m> (the current members that is)
18:06:11 <t8m> except I think one
18:06:14 <nirik> proventester is very easy to attain. ;) Just ask, agree that you read the docs and you are in. ;)
18:06:17 <cwickert> I guess the same for proven tester
18:06:37 <nirik> (although I suppose it shows you can follow process and read docs. ;)
18:06:38 <t8m> yeah, the proventester would seem to me like an easy backdoor
18:06:39 <abadger1999> and proventester is going away if I recall?
18:06:51 <nirik> abadger1999: yeah, thats the last topic which we deferred. ;)
18:06:55 <abadger1999> (as part of changing the critpath requirements)
18:06:59 <mjg59> Honestly if we're broadening it, we might as well just remove all the restrictions
18:07:00 <ajax> abadger1999: we've not ruled on that one way or the other yet.
18:07:16 <abadger1999> ah -- thought it was tentatively approved pending feedback from qa
18:07:24 <nirik> proposal: defer this another week for feedback and ideas?
18:07:44 <pjones> mjg59: last week there were some reasons brought up not to do that, mostly involving ambassadors
18:08:03 <pjones> (and they seemed a little distasteful but not wrong to me)
18:08:30 <nirik> I think the argument was that non tech people would run and be unable to make technical decisions...
18:08:32 <mjg59> pjones: I've no problem with ambassadors standing. If they're competent then I've also got no problem with them being elected.
18:08:37 <nirik> I have no idea how true that would be however.
18:08:57 <mjg59> If we think there's a real risk that inappropriate people would be elected then I think we already have larger problems
18:09:08 * mmaslano would ask QA what do they think
18:09:40 * nirik nods. I'd personally be fine with cla_done + 1...
18:10:27 * abadger1999 thinks there is a risk of inappropriate people being elected but doesn't think it hurts in the long run to try new things.
18:10:32 <t8m> I'd probably prefer to stay with the current rules although I am not strictly against cla_done+1
18:11:52 <nirik> so, proposal to defer? or would someone care to make a counter?
18:12:09 <Viking-Ice> If you open up fesco election you risk turning them into popularity voting contest some one from the design team decides to run and the whole design community votes for him not such a good idea...
18:12:30 <ajax> i'm reasonably sure fesco elections are already popularity contests.
18:12:46 <ajax> vi TODO
18:12:49 <ajax> hah!
18:13:04 * abadger1999 pretty sure they are too... thus, the argument in favor of restricting the candidate pool :-/
18:13:08 <adamw> well, as an entirely anecdotal data point, i don't vote that way.
18:13:17 <drago01> pretty much all elections regardless of context are  popularity contests
18:13:53 * nirik notes also that packager isn't that big a hurdle... just see the last elections. You can find someone to sponsor you if you are at all known to the community.
18:14:07 <t8m> nirik, +1
18:14:31 <t8m> for that reason I'd prefer to stay with the current rules
18:14:38 <drago01> nirik: but who would vote for that person?
18:14:40 <drago01> so ...
18:14:46 <pjones> nirik: yeah, that's looking more and more like a reasonably good point.  Should we just go ahead and endorse that as a plan?
18:14:52 <nirik> drago01: well, I guess we will see? ;)
18:15:00 <drago01> nirik: ;)
18:15:23 <nirik> proposal: leave it as is, ie, requiring packager to run for FESCo ?
18:15:30 <t8m> nirik, +1
18:16:02 <mmaslano> sigh, no reasonable counter proposal, so yes +1
18:16:14 <mjg59> I'd prefer to wait for more community feedback
18:16:36 <pjones> I'm not necessarily against that since it seems to have worked, but I don't see any reason not to wait for more feedback.
18:16:58 * bpepple gives a +1 from the bleachers.
18:17:00 * nirik is ok waiting.
18:17:08 <sgallagh> I'm in favor of sticking with "packager"
18:17:26 <nirik> so, thats 3 for waiting, 3 for packager?
18:18:15 <ajax> i'm for waiting
18:18:25 <ajax> not that there's much difference really.
18:18:30 <nirik> so, really without passing anything we fall back to waiting?
18:18:33 <ajax> since a vote to wait is a vote to keep it as it is for now.
18:18:33 <nirik> yeah.
18:19:22 <nirik> ok, so I guess we defer by lack of any other thing passing. ;)
18:19:36 <nirik> #action defer to next week, collect feedback and revisit.
18:19:50 <nirik> #topic #690 F17 Feature: move all to /usr https://fedoraproject.org/wiki/Features/UsrMove
18:19:51 <nirik> .fesco 690
18:19:54 <zodbot> nirik: #690 (F17 Feature: move all to /usr - https://fedoraproject.org/wiki/Features/UsrMove) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/690
18:20:31 <ajax> the more i read this the more it sounds entirely sensible.
18:20:43 <mjg59> +1
18:20:45 <t8m> -1
18:20:55 * pjones is +1 as well
18:20:57 <mmaslano> -1
18:20:57 <nirik> notting was a +1 in ticket with: "I'm tentatively OK with this, although I have concerns about the implementation on upgrade - I don't want to have a /bin directory with a forest of symlinks inside it, for example."
18:21:10 <t8m> I did not change my opinion that it is a solution looking for a problem
18:21:11 <abadger1999> nirik: actually -- that would be a -1  wouldn't it?
18:21:11 <mjg59> Although I lean somewhat towards being concerned about the /bin+/sbin merging
18:21:21 <abadger1999> nirik: Since there is no implementation that doesn't do that?
18:21:31 <nirik> abadger1999: good point
18:21:44 <t8m> I am definitely against the /bin /sbin merging
18:21:47 <abadger1999> mjg59: FPC has said no to that portion as well.
18:21:56 <ajax> bin/sbin isn't a huge win imo
18:22:29 <abadger1999> mjg59: I'd suggest that fesco take that portion out of the feature to avoid the further discussions that leaving it in would entail.
18:22:34 * abadger1999 nods at ajax
18:23:02 <ajax> i also have some reservation about relying on the initramfs so much, we've already got at least one bug against f16 where it sticks around for your entire boot cycle just so you can tear down raid cleanly at shutdown
18:23:06 <nirik> I'm still concerned with the amount of work here vs gain. It's changing 900 of our packages in order to... have more things in /usr so it's easier to have remote mounted /usr ?
18:23:18 <mjg59> I see 3 +1s and an argument about what notting means
18:23:31 <mmaslano> nirik: that's also my concern + implementation
18:23:57 <nirik> haraldh: are you around to answer questions?
18:24:25 <haraldh> sure
18:24:30 <ajax> nirik: remote /usr is already a thing people claim to want though.
18:24:38 * nirik notes cwickert was +1 in the ticket earlier as well.
18:24:48 <haraldh> without sbin/bin it's a lot less packages to touch
18:25:15 <nirik> without moving them at all? or without merging them?
18:25:26 <haraldh> without merging them
18:25:37 <nirik> how so? you still need to touch them to move them?
18:25:38 <t8m> cwickert, Are you still +1 on this?
18:25:52 <cwickert> t8m: yes
18:25:56 <haraldh> nirik, sure, but not /usr/sbin
18:26:12 <nirik> haraldh: ok, right.
18:26:20 <kay> the thing with bin+sbin was that if we have simlinks all pointing to /usr/bin every location works the same. and it does not matter anymor who puts which tool where. we have both by default in $PATH anyway
18:27:08 <ajax> kay: we do have both in path, but search order still matters for some things.
18:27:30 <haraldh> ajax, which nobody should rely on
18:27:31 <nirik> abadger1999: can you pass on the FPC reasoning on that decision? or is it long?
18:27:32 <haraldh> anyway..
18:27:33 <kay> ajax: which tools?
18:27:43 <ajax> kay: anything that uses consolehelper, at a minimum.
18:27:53 <kay> ajax: that is going away
18:28:06 <t8m> kay, how so?
18:28:26 <t8m> kay, have you already prepared patches for all the packages that use consolehelper?
18:28:50 <kay> ajax: relying on initramfs is only when you decide to split off /usr, nothing changes when / and usr is on the same partition
18:28:50 <ajax> kay: yeah, so's X.
18:29:13 <kay> ajax: ?
18:29:15 <haraldh> t8m, "move consolehelper real binaries from /usr/sbin/* to /usr/lib/<pkgname>/<tool> or /usr/libexec/<tool> and change consolehelper to look in these places. "
18:29:27 <haraldh> that is on the feature page
18:29:31 <haraldh> not good enough?
18:29:51 <t8m> haraldh, it is still sometimes useful for root to call the binaries directly without the consolehelper influence
18:30:03 <ajax> kay: "it's going away" isn't an argument that holds a lot of water with me, given how many releases it took to drop hal, and how many it's still taking to drop consolekit.
18:30:09 <haraldh> t8m, nobody prevents the superuser to do that with the full path
18:30:14 <t8m> haraldh, and as for root sbin is before bin in $PATH that is the current status
18:30:17 <ajax> kay: if it's not _gone away_ it's not gone and not something you get to just brush aside.
18:30:20 <t8m> haraldh, bleach
18:30:43 <abadger1999> nirik: details are in the FHS basically.  Merging /bin and /usr/bin (and the other directories mentioned) would not violate the letter or spirit of the FHS (with the initramfs distinction)
18:31:30 * nirik sees -2, +4 and one +1perhaps from notting.
18:31:31 <abadger1999> nirik: contrariwise, /sbin and /bin are separated in the FHS due to organization and so merging them is a violation of the FHS.
18:31:43 <kay> ajax: but hal is gone, and ck will go too. it just takes a while sometimes, when no immediate pressure requires to get rid of something. but i don't think we had any serious problems with that approach. did we?
18:32:15 <mmaslano> nirik: I don't see how it could be approved, when FPC disagree at least with some points
18:32:22 <kay> abadger1999: fhs forbids libexec too :)
18:32:33 <ajax> kay: i think "serious problems" depends on the scope of who you're talking to, and beyond that i think we're getting off-topic.
18:32:37 <nirik> mmaslano: those parts need to be dropped or they need to convince FPC I guess.
18:32:42 <mjg59> We can certainly approve it subject to certain aspects being negotiated with FPC
18:32:51 <abadger1999> kay: Yes.  But we've specifically excepted that due to conflicting advice from the GNU Coding standardds.
18:33:04 <abadger1999> kay: bin and sbin are separated in the GNU coding standards as well.
18:33:17 <abadger1999> kay: So merging them would violate both standards.
18:33:35 <haraldh> it does not "violate" the standards
18:33:36 <ajax> anyway, like i say, i think this is a wholly reasonable thing to try to do.  i forsee issues but that's not new.
18:33:41 <nirik> proposal: have feature owners adjust feature to meet FPC / FHS and revisit.
18:33:43 <kay> abadger1999: no we would only have the tools available in both directories at the same time :)
18:33:59 <haraldh> I don't think anywhere is mentioned: "All sysadmin tools have to be in /sbin"
18:34:13 <nirik> (additionally, ask notting to clarify his /bin symlinks proviso)
18:34:16 <haraldh> it's only : "if there is /sbin, sysadmin tools should be in there"
18:34:25 <mmaslano> nirik: I guess we have no other possibility
18:34:29 <mjg59> I don't see any benefit in asking them to talk to FPC first
18:34:35 <mjg59> Either FPC agree and then we have the conversation again
18:34:40 <mjg59> Or FPC disagree and it makes no difference
18:34:44 <mjg59> Let's just vote on *our* position
18:34:49 <pjones> yeah
18:34:56 <mjg59> With nothing we say to be taken as overruling FPC
18:35:03 <abadger1999> haraldh: you can claim that it doesn't violate the FHS but in Fedora, the FPC decides that.
18:35:19 <mjg59> And I have no interest at all in having an argument about what the FPC thinks or doesn't think right now
18:35:22 <mjg59> This isn't the venue
18:35:24 * nirik thinks we have empowered the FPC to handle guidelines, and shouldn't overrule them.
18:35:26 <haraldh> abadger1999, just my humble opinion :)
18:35:29 <pjones> abadger1999: Ehhh... let's not have that discussion, shall we?
18:35:41 <t8m> nirik, I agree
18:36:00 <mjg59> Anyway
18:36:08 <mjg59> haraldh: Do you have any response to notting's concern?
18:36:09 <nirik> anyhow, I'm -1
18:36:11 <abadger1999> haraldh: I constantly recommend just getting rid of that part so that this can go through the Feature process more quickly instead of going to FPC to be deliberated on and then back to fesco.  But... if it's that crucial, you can send it there :-)
18:36:18 * cwickert needs to leave now
18:36:22 <nirik> so, that leaves -3, +4 and ? from notting.
18:36:35 <haraldh> mjg59, that's the transition phase for safety reasons...
18:36:48 <sgallagh> I still remain -1
18:36:51 <haraldh> mjg59, we don't want to destroy people's systems
18:36:58 <mjg59> Ok so I think what's going to have to happen is you discuss that with notting in the ticket
18:37:05 <sgallagh> I haven't been convinced that there's any benefit (other than remote /usr) to this proposal
18:37:11 <nirik> notting seems to be the swing vote. ;)
18:37:11 <mjg59> And if you can convince him then you get to do this and if you can't then you don't
18:37:19 <sgallagh> And it's asking a lot of maintainers
18:37:44 <haraldh> mjg59, he didn't say +/- 0 ... notting said +1
18:37:53 <mjg59> haraldh: He said +1 conditional on something
18:37:58 <nirik> notting was a +1 in ticket with: "I'm tentatively OK with this, although I have concerns about the implementation on upgrade - I don't want to have a /bin directory with a forest of symlinks inside it, for example."
18:38:10 <mjg59> haraldh: So just settle that and then we're done
18:38:15 <kay> notting last week: "<notting> i am a moderate +1"
18:38:26 <haraldh> mjg59, ok, will do
18:38:49 <mjg59> I suspect that he'll be ok with things but I also don't want to put words in his mouth
18:38:53 <nirik> I'd prefer not to second guess him... when we can ask him in ticket.
18:39:02 <mjg59> So let's just do that
18:39:04 <t8m> I'd really prefer if on such split vote we had clear votes from each member
18:39:18 <t8m> and not any last week votes or ticket votes with conditionals
18:39:29 <haraldh> if he didn't want it, he would have said -1 ... if he was tentative enough .. he would have said 0
18:39:46 <nirik> so, action: -4 votes, +4 votes, feature owners will consult with remaining fesco member in ticket. ?
18:39:52 <haraldh> right
18:39:59 <nirik> t8m: I think we had clear votes from everyone here...
18:40:14 <t8m> nirik, yes, I am talking about the notting's ticket vote
18:40:32 <nirik> t8m: you prefer we wait until next week?
18:40:36 <t8m> nirik, sure
18:40:46 <nirik> why not have him read this and vote in ticket tho?
18:40:52 <mjg59> I'm fine with him voting in the ticket
18:40:56 <sgallagh> Sure
18:41:14 <abadger1999> nirik: FPC meets on Wed -- If notting gets back to you before then, could you be sure to file an FPC ticket and mark it meeting?
18:41:17 <t8m> ok if he clearly votes in the ticket without any conditional then I am fine with that
18:41:38 <nirik> #action: -4 votes, +4 votes, feature owners will consult with remaining fesco member in ticket.
18:41:55 <nirik> #action nirik to file FPC ticket for looking over things vs guidelines.
18:41:59 <nirik> Anything more on this?
18:42:16 * nirik will move on in a sec.
18:42:18 * abadger1999 assumes we'll get quorum in fpc... since no one sent out the new DST adjusted/not adjusted schedule I don't know about that :-(
18:42:29 <t8m> Yeah, I'm curious who will do the work on changing the hundreds of packages.
18:42:41 <nirik> thanks for coming haraldh / kay. :) Appreciate it.
18:42:55 <abadger1999> t8m: shouldn't that be part of the feature process?
18:42:59 <nirik> t8m: same as for systemd... maintainers and provenpackagers I guess.
18:43:06 * abadger1999 runs
18:43:09 <nirik> #topic #693 IPv6 support requirement in Fedora package
18:43:10 <nirik> .fesco 693
18:43:11 <zodbot> nirik: #693 (IPv6 support requirement in Fedora package) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/693
18:43:14 <t8m> abadger1999, should probably - that's one of the reasons for my -1
18:43:37 <ajax> oh good, a slapfight.
18:43:38 * abadger1999 checks if that's one of the critiques on rbergeron's page
18:43:58 <nirik> ok, so perhaps we should punt this to FPC?
18:44:35 <t8m> I am not so sure it's a packaging issue.
18:44:53 <t8m> It is mostly upstream functionality issue.
18:45:08 <ajax> i have to duck out for a minute, but regardless of whose issue this is, seriously, ipv6 is not an option.
18:45:24 <sgallagh> The most we could do is block packages that aren't IPv6-capable. (I'm -1 to that).
18:45:33 <sgallagh> I don't think we can really enforce anything beyond that
18:45:54 <t8m> although the concrete vsftpd example is a slightly more complicated
18:46:01 <nirik> I think it would be fine to add a "SHOULD" on ipv6 support, but we can't force people to create it if it doesn't exist. This issue just seems like a upstream bug.
18:46:14 <haraldh> :)
18:47:13 <nirik> so, any proposals?
18:47:17 <abadger1999> I think we (where we == "some fesco in the past") supported dwmw2's position.
18:47:26 <pjones> nirik: huh?  as I read it upstream has the feature and we're disabling it by default
18:47:31 <abadger1999> if upstream has ipv6 support, the Fedora package must support it too.
18:47:34 <dwmw2> oh, is it Monday?
18:47:49 <nirik> hey, it is.
18:47:50 <t8m> we do not disable ipv6 support
18:47:51 <dwmw2> the package has IPv6 support
18:47:54 <t8m> in vsftpd
18:47:56 <mjg59> Well the specific case is clearly one where upstream would work but we've broken it
18:48:24 <mjg59> Is there a more general problem or are we really being asked to provide guidance based on one example?
18:48:37 <nirik> dwmw2: what action are you looking for here?
18:48:52 <dwmw2> slap the damn packager and tell him not to be so bloody stupid :)
18:48:55 <mmaslano> dwmw2: did you read maintainer replies?
18:49:13 <dwmw2> I want the vsftpd package to listen on IPv6 and IPv4 by default, like all Fedora packages should be.
18:49:30 <nirik> yeah, wow. the ipv6 only stuff is a patch.
18:49:35 <mmaslano> dwmw2: even if upstream didn't take that patch?
18:49:41 <dwmw2> mmaslano: which patch?
18:49:43 * nirik misread it first
18:49:53 <dwmw2> we patched it to break it :)
18:49:54 <mmaslano> dwmw2: it's in the ticket
18:50:10 <dwmw2> it *used* to work when you just listen on ::. It would accept both IPv6 and Legacy IP connections on the same socket
18:50:40 <nirik> proposal: in this case tell maintainer to please support listening on both. additionally, file FPC ticket to ask them to add a 'SHOULD: should support both ipv6 and ipv4 connections if support exists' ?
18:50:44 <dwmw2> we patched it so that doesn't work any more. You have to run two separate dæmons; one for IPv6 and one for IPv4. Which would be kind of OK if we actually shipped the two initscripts and two configs by default... if a bit daft.
18:51:01 <dwmw2> nirik: that's fairly much what I was thinking
18:51:17 * nirik is +1 to that.
18:51:48 <dwmw2> mmaslano: you mean the fesco ticket 693? Yes, I read that. Right before I replied, in the ticket :)
18:52:56 <nirik> other votes? comments? counter proposals?
18:53:11 <sgallagh> +1
18:53:18 <t8m> nirik, why not, +1
18:53:19 <mjg59> +1 I guess
18:53:32 <gholms> They should support both... at the same time or not?
18:53:49 <dwmw2> gholms: define 'at the same time'.
18:54:00 <gholms> Because the current behavior in this specific case falls within the letter of that rule.
18:54:06 <pjones> nirik: +1
18:54:07 <dwmw2> I don't think it matters if it's from the same dæmon or not. Not from FESCo's point of view.
18:54:15 <gholms> Okee dokee
18:54:15 <nirik> #agreed tell maintainer to please support listening on both ipv4 and ipv6 in vsftpd. additionally, file FPC ticket to ask them to add a 'SHOULD: should support both ipv6 and ipv4 connections if support exists' ?
18:54:24 <gholms> Sorry, everyone
18:54:31 <skalnik_rh> maintainer is listening
18:54:34 <nirik> would someone like to step up to talk to the maintainer and/or file the FPC ticket?
18:54:40 <dwmw2> gholms: well, the current behaviour would only be OK if the package shipped a config for ipv4 *and* a config for ipv6, and initscripts to start the dæmon with both
18:54:41 <dwmw2> surely?
18:54:43 <nirik> ah, welcome skalnik_rh
18:55:18 <nirik> skalnik_rh: anything to add/input here?
18:55:26 <gholms> dwmw2: Yes, that makes sense.
18:55:48 <dwmw2> gholms: which is one of the potential remedies listed when I originally filed the ticket.
18:56:19 <dwmw2> I deliberately kept the technical details *out* of the FESCo issue though; FESCo only really cares about policy. It should be fixed; it's up to the maintainer *how* to fix it.
18:56:19 <skalnik_rh> i wrote everything but only repeat. i'd like to support both possibilities ipv4+6 but also separate
18:56:23 <nirik> yeah... although it seems kinda a waste of resources.
18:56:54 <dwmw2> nirik: two dæmons seems like a waste of resources? Well yes, it's stupid. But at least it's not *broken*. So I wouldn't be whinging to FESCo about it :)
18:56:59 <nirik> skalnik_rh: so, sounds like the solution is the one dwmw2 suggested... ship two unit files, one for each?
18:57:24 <dwmw2> I would prefer to fix the code really, so it can listen on both again. Just drop the offending patch, fix the default config file to listen on IPv6 (which accepts IPv4 too)
18:57:24 <t8m> nirik, I do not think we need to discuss the concrete solution here
18:57:32 <dwmw2> but I don't think FESCo should mandate *which* solution is used
18:57:43 <t8m> yeah
18:57:47 <nirik> right.
18:57:47 <mmaslano> could we go to next topic, please
18:58:00 <dwmw2> was that "a fix should be available for f16" ?
18:58:02 <nirik> would anyone care to step up to file the fpc ticket?
18:58:04 <dwmw2> rather than only in f17?
18:58:35 <nirik> dwmw2: depends on the solution possibly...
18:58:59 <dwmw2> well, maybe the requirement to update f16 would affect the choice of solution :)
18:59:01 <nirik> ok, I guess I will.
18:59:06 <dwmw2> dropping the silly patch *is* feasible in an update.
18:59:14 <nirik> #action nirik to file FPC ticket about ipv6 support.
18:59:23 <dwmw2> shipping a second config+initscript probably is too
18:59:47 <nirik> dwmw2: if it doesn't change the user experence any, sure, fixing it in stable releases sounds find.
18:59:49 <nirik> fine.
18:59:57 * nirik will move on to the next topic then...
19:00:01 <dwmw2> thanks
19:00:12 <nirik> #topic #694 Consider sanctions against glibc
19:00:12 <nirik> .fesco 694
19:00:13 <zodbot> nirik: #694 (Consider sanctions against glibc) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/694
19:00:42 <nirik> so, we have had no communication from glibc maintainers that I know of here.
19:00:48 <mjg59> jsmith: Anything from you here?
19:00:58 <mmaslano> proposal: do not rebase until alpha ;-)
19:00:59 <jsmith> mjg59: Yes...
19:01:13 <jsmith> So, I've been working with the glibc maintainer and his supervisor at Red Hat
19:01:19 <sgallagh> mmaslano: counter-proposal: do not allow rebase AFTER alpha :)
19:01:29 <mmaslano> sgallagh: damned English
19:01:30 <jsmith> I think we're to the point where we need to restrict his packaging privileges
19:01:57 <nirik> :(
19:02:14 <jsmith> I'm sad to see it get to this point, but it was one of his supervisors who suggested that it is time
19:02:25 <nirik> so, reassign the package?
19:02:34 <jsmith> I'll all ears for suggestions on how to best handle this
19:02:36 <ajax> so now we need to get someone to fall on the grenade.
19:02:46 <nirik> yeah, thats the difficult part for sure.
19:02:53 <t8m> ajax, :)
19:02:57 <drago01> ajax: did you just volunter for that? ;)
19:03:25 <t8m> drago01, who will be the X maintainer after the grenade explodes?
19:03:29 <jsmith> I suggest we ask Jeff Law if he'd be willing to take the package, at least in the short term
19:03:32 <nirik> is there any upstream developer community we could talk with and see if anyone there is interested in helping out?
19:03:37 <pjones> his supervisor's suggestion was to have him (the supervisor who we're not naming for unknown reasons) have signoff for all changes
19:03:42 <drago01> t8m: ;)
19:03:46 <pjones> which pretty much means the supervisor is falling on that grenade AFAICS
19:03:54 <ajax> i'd happily be part of a team looking after glibc, but i don't have anywhere near the time to devote to it full-time.
19:04:04 <pjones> jsmith: Jeff is the supervisor we're talking about, right?
19:04:17 <nirik> so, we remove commit for the current maintainer, and add for jefflaw?
19:04:23 <pjones> nirik: right
19:04:35 <jsmith> pjones: Jeff is one of the people supervising... but there are several supervisors involved.  In short, "it's complicated"
19:04:45 <nirik> I'm happy to do that if it will improve the situation.
19:04:47 <pjones> jsmith: *nod*
19:05:07 <jsmith> pjones: But yes, Jeff is helping take care of some glibc tasks, and is trying to follow glibc packaging as closely as he can
19:05:23 <pjones> so what would the workflow look like, then?  andreas asks jeff to do a git pull?
19:05:24 * nirik notes law already has commits and approveacls on it.
19:07:05 <nirik> pjones: something like that I assume...
19:07:11 <ajax> sounds pretty resolved then.
19:07:44 <nirik> well, I guess the last action here for us is removing acls for the current maintainer for now?
19:07:49 <pjones> ue[p
19:07:50 <pjones> yep.
19:07:55 <jsmith> Yeah, that sounds correct to me
19:08:00 <mjg59> Ok
19:08:06 <mjg59> jsmith: Thanks for working on this
19:08:15 <jsmith> mjg59: No worries -- it was painful, but needed to be done
19:08:23 <nirik> do we remove them from packager? or just glibc ?
19:08:36 <sgallagh> I think just glibc
19:08:45 * nirik notes they are co-maintainer on a few other packages.
19:08:52 <jsmith> Let me also point out that I'm more than willing to reinstate packaging privileges for the maintainer, if/when they agree to start communicating better and working within our packaging guidelines
19:09:46 <nirik> proposal: remove ownership/acls for current glibc maintainer.
19:09:55 <ajax> (from glibc) +1
19:09:57 <nirik> proposal: remove ownership/acls for current glibc maintainer on the glibc package.
19:10:06 <pjones> nirik: +1
19:10:13 <nirik> +1 here sadly.
19:10:16 <mmaslano> +1
19:10:22 <t8m> nirik, +1 unfortunately
19:10:39 <sgallagh> nirik: +1
19:10:39 <nirik> #agreed remove ownership/acls for current glibc maintainer on the glibc package.
19:10:45 <nirik> jsmith: thanks for digging into this.
19:11:07 <nirik> if nothing else moving on.
19:11:09 <sgallagh> Should we make any kind of announcement about this?
19:11:25 <sgallagh> I mean, the glibc instability has been biting a lot of packagers/developers for the last few months
19:11:35 <jsmith> sgallagh: Short of informing the packager in question, I'd rather not make a huge deal of it
19:11:37 <abadger1999> Clarification
19:11:38 <sgallagh> I don't want to publicly shame the packager
19:11:44 <abadger1999> Are we just removing his acls from glibc?
19:11:52 <abadger1999> (The only package he owns)
19:11:53 <nirik> abadger1999: and ownership over to law
19:12:03 <abadger1999> Or from the packages that he comaintains as well?
19:12:06 <abadger1999> https://admin.fedoraproject.org/pkgdb/users/packages/schwab?acls=owner&acls=approveacls&acls=commit
19:12:08 <sgallagh> abadger1999: Only glibc
19:12:09 <nirik> just glibc
19:12:14 <abadger1999> Okay.
19:12:20 <abadger1999> I'll take care of that.
19:12:24 <mjg59> Given that this is a matter of public record now, I don't think we need to say anything else
19:12:24 <nirik> thanks abadger1999
19:12:35 <nirik> yeah, I don't think we want/need any announcement.
19:12:53 <nirik> #topic #695 Recommend 64-bit download by default
19:12:53 <nirik> .fesco 695
19:12:54 <zodbot> nirik: #695 (Recommend 64-bit download by default) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/695
19:13:12 <nirik> +1 from me. Lets move incrementally into the current day. ;)
19:13:25 <t8m> +1 from me as well
19:13:31 <mjg59> +1
19:13:37 <mjg59> Given that even Atom is 64-bit now
19:13:45 <Southern_Gentlem> ?
19:13:46 <nirik> even arm! ;)
19:13:50 <mmaslano> I don't care. I think many people have netbooks, which stil needs i686
19:13:53 <nirik> Southern_Gentlem: fire away
19:14:18 <Southern_Gentlem> why does there have to be one default why not point at both the 32 and 64 bit
19:14:47 <nirik> well, it's hard to present that choice I think in a way that everyone understands.
19:14:48 <Southern_Gentlem> we get at least 10 questions a day in #fedora which one should i download
19:15:03 <ajax> Southern_Gentlem: and you think offering more choices will _reduce_ that number?
19:15:19 <Southern_Gentlem> no but at least we have them coming and asking
19:15:31 <drago01> yeah please its 2011 already ... lets move on
19:15:39 <ajax> then i have difficulty connecting your two statements.
19:15:44 <nirik> what does the x86_64 media do when you boot it on a 32bit platform?
19:15:48 <abadger1999> Did the message from Neville Cross get read by people here or did it only go to the FAB list?
19:15:53 <drago01> nirik: it complains on boot
19:15:58 <ajax> nirik: prints a message saying it won't boot, last i checked
19:16:06 <Southern_Gentlem> it would be easy for the website team say i686 (32bit for older machines)  x86_64 (new machines 64bit
19:16:15 <drago01> define old and new
19:16:22 <drago01> 64bit has been around since 2003
19:16:31 <nirik> yes, but could it instead say: "You need the 32bit media, sorry" at least?
19:16:40 <nirik> abadger1999: I think only the board list.
19:16:47 <mjg59> The 64-bit media will throw an obvious error if you try to boot it on 32-bit
19:16:56 * abadger1999 digs up a link
19:17:02 <ajax> the correct thing to do is still biarch media
19:17:05 <nirik> http://lists.fedoraproject.org/pipermail/advisory-board/2011-November/011037.html
19:17:13 <mjg59> ajax: Sure, we could do that for DVD
19:17:17 <Southern_Gentlem> drago01,  and alot of other countries have not caught up to the new hardware yet
19:17:19 <abadger1999> http://lists.fedoraproject.org/pipermail/advisory-board/2011-November/011037.html
19:17:28 <drago01> ajax: once we decide to get rid of CDs ..
19:17:32 <dwmw2> we know biarch installs work fairly well; we did it for a long time on ppc
19:17:42 <abadger1999> Yeah, just some statistics since there's usually a lack of those in the discussions.
19:17:45 <ajax> drago01: desktop live is <600M these days, it could be less...
19:18:29 * pjones is also +1 on recommending 64-bit by default
19:18:43 <mjg59> +1 on the recommendation. We're not proposing dropping 32-bit media.
19:18:48 <drago01> Southern_Gentlem: new as in almost a decade (8 year) old?
19:18:49 <nirik> abadger1999: does the freemedia form just ask?
19:18:52 <lmacken> just for reference, our i686 live desktop torrent is still downloaded more than the 64 bit.
19:19:02 <nirik> lmacken: because it's default perhaps?
19:19:03 <drago01> not sure any of such hardware can run fedora well enough anyway
19:19:05 <abadger1999> Southern_Gentlem: Do you know the answer to that?
19:19:09 <lmacken> nirik: quite possibly
19:19:32 <sgallagh> What are we claiming as minimum system requirements for Gnome 3?
19:19:34 <t8m> I still count just +4.
19:19:39 <Southern_Gentlem> abadger1999,  i think in 3 -5 years we will be able to drop 32bit but not yet
19:19:54 <ajax> sgallagh: i don't think that's well-defined tbh
19:19:58 <Southern_Gentlem> but that is a different discussion
19:20:17 <drago01> sgallagh: a "decent" gpu as intel gen3+; r300+ or nv40+ (30?)
19:20:25 <sgallagh> I tend to agree with drago01 that chances are, any system that can run Gnome3/KDE4 reasonably is likely to be 64-bit aready
19:20:32 <ajax> i guess i don't really know what we'd hope to gain by changing the default
19:21:00 <drago01> ajax: make people get the right think by default
19:21:57 * sgallagh notes that even Microsoft is shipping 64-bit Windows with 64-bit systems
19:22:01 <ajax> drago01: begging.  define "right".  i mean, yes, amd64 is a nicer ISA, but i really don't think the performance win is much more than psychosomatic.
19:22:03 <t8m> If there is substantial amount of our users with >4GB RAM we are making it easier for them to choose the right release.
19:22:07 <nirik> The freemedia form just files a trac ticket... so I guess it depends on the template there.
19:22:19 <Southern_Gentlem> nirik,  yep
19:22:37 <drago01> ajax: address space, security
19:22:38 <ajax> +1 i guess.  probably harmless.
19:22:38 <nirik> migrating more people to 64 means they are already over there when we finally kill 32bit? ;)
19:23:23 <nirik> so, thats +5?
19:23:32 <sgallagh> I'm +1
19:23:52 <nirik> #agreed will promote 64bit as default for f17. websites to determine the best way to present things.
19:24:06 <nirik> oh, notting was also +1
19:24:30 <nirik> #topic #696 F17 Feature: Gnome Shell Configurability https://fedoraproject.org/wiki/Features/GnomeShellConfigurability
19:24:30 <nirik> .fesco 696
19:24:35 <zodbot> nirik: #696 (F17 Feature: Gnome Shell Configurability - https://fedoraproject.org/wiki/Features/GnomeShellConfigurability) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/696
19:25:00 <sgallagh> Proposal: stick with upstream but try to convince them to stop breaking extensions with every update.
19:25:01 <nirik> notting is -1 in ticket
19:25:14 <mjg59> sgallagh: Extension stability is committed to for 3.4
19:25:28 <sgallagh> mjg59: Good to hear
19:25:33 <ajax> extension ABI is one of those intrinsically difficult things though
19:25:40 * nirik is -1 and suggests feature owner just work with the desktop team
19:25:44 <pjones> I'm -1 .  The idea is sortof okay (a bit malformed...) but we should really let upstream work this on their own time.
19:25:49 <drago01> mjg59: not true
19:25:56 <drago01> mjg59: there is no defined api
19:26:04 <drago01> mjg59: extensions can change *anything*
19:26:34 <nirik> thats -3 so far. more votes, proposals?
19:26:37 <sgallagh> Well, I'd like to see Gnome upstream working a little less in a vacuum
19:26:39 <mjg59> Really? I must have misunderstood.
19:26:40 <sgallagh> I'm -1
19:26:40 <mjg59> Anyway, -1
19:26:58 <t8m> sgallagh, heh, I'd like that too
19:27:07 <sgallagh> Right now, they're development path is leading them directly into mass migration away
19:27:11 <sgallagh> s/they're/their/
19:27:31 <nirik> #agreed Feature is rejected at this time. Feature owner should work with desktop team/gnome upstream.
19:27:34 <ajax> sgallagh: the talk page mentions launching a website for extension management
19:27:35 <nirik> #topic #697 F17 Feature - ConsoleKit Removal/Automatic Multi-Seat Support - https://fedoraproject.org/wiki/Features/ckremoval None
19:27:35 <nirik> .fesco 697
19:27:37 <zodbot> nirik: #697 (F17 Feature - ConsoleKit Removal/Automatic Multi-Seat Support - https://fedoraproject.org/wiki/Features/ckremoval) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/697
19:27:44 <mjg59> +1
19:27:48 <ajax> sgallagh: which i'm reasonably sure is there so they have metrics on usage
19:27:53 <ajax> (among other things)
19:28:00 <nirik> notting is +1 for this in ticket.
19:28:19 <ajax> +1, wish this had made f16 tbh
19:29:08 <t8m> OK +1 with hope that it will not break non-gnome desktops
19:29:27 <ajax> t8m: non-gnome is already not using it in f17...
19:29:29 * nirik is +1 for this with the proviso that it doesn't break other desktops... which was the case for the f16 version.
19:29:33 <mmaslano> +1 because discussion page claims that non-gnome will work
19:29:38 <pjones> definitely +1 here
19:29:45 <nirik> #agreed Feature is approved.
19:29:49 <sgallagh> I'm with nirik
19:30:17 <nirik> #topic #698 F17Feature: SysV to Systemd - https://fedoraproject.org/wiki/Features/SysVtoSystemd
19:30:17 <nirik> .fesco 698
19:30:19 <zodbot> nirik: #698 (F17Feature: SysV to Systemd - https://fedoraproject.org/wiki/Features/SysVtoSystemd) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/698
19:30:51 <nirik> +1, and I think we should re-iterate that provenpackagers are fine to commit changes.
19:30:51 <mjg59> +1
19:30:57 <nirik> and notting was +1 in ticket
19:31:04 <sgallagh> +1
19:31:05 <ajax> +1
19:31:14 <pjones> nirik: +1 with your note.
19:31:29 <nirik> #agreed Feature is approved.
19:31:33 <nirik> #topic Consider including bash-completion package by default (base, not core)
19:31:33 <nirik> .fesco 689
19:31:34 <zodbot> nirik: #689 (Consider including bash-completion package by default (base, not core)) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/689
19:31:53 <nirik> I don't use bash, but sure, +1 here... I think some folks will find it handy and it's small.
19:32:03 <mjg59> +1 but agree that network-using bits should be disabled by default
19:32:10 <jwb> please
19:32:11 <nirik> nothing was +1 with no network.
19:32:16 <sgallagh> +1 with no network
19:32:19 * pjones is also +1 with no network
19:32:21 <t8m> I am +1 with no network
19:32:22 <ajax> +1 no netwokr
19:32:28 <nirik> notting. sheesh. can't type today.
19:32:31 <ajax> it's almost useful enough to make me switch back from zsh
19:32:37 <nirik> #agreed Feature is approved.
19:32:47 <nirik> well, thing is approved... I guess it's not a feature.
19:32:56 <nirik> #topic Open Floor
19:33:03 <nirik> Anyone have anything for open floor?
19:33:51 <t8m> nirik, the next week chair?
19:34:00 <nirik> yeah, good point. Who wants it? ;)
19:34:17 <ajax> amusingly, bash-completion is already in @base default in comps.
19:34:26 <ajax> commit 3a88e770f8950dedb0820fa7ca5892250e7a8908
19:34:26 <ajax> Author: Ville Skyttä <ville.skytta at iki.fi>
19:34:26 <ajax> Date:   Wed Jul 27 23:42:26 2011 +0300
19:34:27 <ajax> Move bash-completion to @base as default (#709647).
19:34:29 <ajax> so there's that
19:35:12 <t8m> heh
19:35:15 <ajax> i don't know if i'm going to be around next monday, so i must decline for the moment
19:35:32 <sgallagh> same here
19:36:09 <mjg59> I'll do it
19:37:19 <nirik> #action mjg59 to chair next week.
19:37:24 <nirik> any other items today?
19:38:48 <shaiton> .PingLists doping frenchteam Réunion Fedora-Fr maintenant sur #fedora-meeting-1
19:38:50 * nirik listens to the crickets.
19:38:52 <shaiton> (sorry guys)
19:39:08 <nirik> ok, thanks for coming everyone.
19:39:11 <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/20111114/b8b4a94b/attachment-0001.bin 