17:00:08 <mjg59> #startmeeting FESCO (2012-04-23)
17:00:08 <zodbot> Meeting started Mon Apr 23 17:00:08 2012 UTC.  The chair is mjg59. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:08 <mjg59> #meetingname fesco
17:00:08 <mjg59> #chair notting nirik mjg59 mmaslano t8m pjones sgallagh mitr limburgher
17:00:08 <mjg59> #topic init process
17:00:08 <zodbot> The meeting name has been set to 'fesco'
17:00:08 <zodbot> Current chairs: limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m
17:00:16 <mjg59> Ok, who's here this week?
17:00:17 <pjones> hello.
17:00:20 * nirik waves
17:00:22 <mmaslano> hi
17:00:26 <sgallagh> Hi
17:00:41 <nirik> I'll note that I will in fact NOT be here next week. ;)
17:00:45 * limburgher here
17:01:24 <t8m> hello
17:01:24 * notting is here
17:01:37 <mjg59> mitr: Around?
17:01:41 <mitr> Hello
17:01:47 <mjg59> Excellent, full house
17:02:00 <mjg59> So, let's get going
17:02:02 * sgallagh reveals a straight flush
17:02:10 <mjg59> I'm going to propose we leave the secondary architecture stuff to the end?
17:02:18 <mmaslano> agree
17:02:20 <sgallagh> Sure
17:02:21 <pjones> yeah
17:02:26 <mjg59> Ok
17:02:29 <mjg59> #topic #829     New proven packagers request: Pavel Alexeev (hubbitus)          .fesco 829
17:02:34 <nirik> mjg59: I dropped the ball here.
17:02:36 <mjg59> .fesco 829
17:02:37 <nirik> we approved this last time.
17:02:37 <zodbot> mjg59: #829 (New proven packagers request: Pavel Alexeev (hubbitus)) – FESCo - https://fedorahosted.org/fesco/ticket/829
17:02:42 <mjg59> Yeah, thought so
17:02:43 * nirik will go fix it.
17:02:46 <mjg59> Thanks!
17:02:52 <mjg59> That's a really easy one
17:03:01 <mjg59> #topic #838     https://fedoraproject.org/wiki/Features/firewalld-default status
17:03:06 <mjg59> .fesco 838
17:03:07 <zodbot> mjg59: #838 (https://fedoraproject.org/wiki/Features/firewalld-default status) – FESCo - https://fedorahosted.org/fesco/ticket/838
17:03:25 <notting> concern is no GUI tool?
17:03:29 <mjg59> twoerner: We're past beta and this doesn't seem feature complete yet?
17:03:33 <mitr> I have taken a more detailed look today
17:03:34 <mjg59> notting: Yup
17:03:42 <mitr> 1) the basic use cases work, and the UI is much nicer than iptables
17:03:46 <nirik> I really don't like all the work on this past beta
17:03:50 <twoerner> mjg59: the features are there in my opinion
17:03:51 <notting> i could have sworn that 'no gui tool' was explicilty in the feature when we approved it
17:04:00 <mitr> 2) GUI users will disable it (no GUI, printer support missing in s-c-printer, will break after reboot with printers configured in control-center)
17:04:07 <pjones> notting: yeah, that rings a bell with me as well
17:04:08 <mitr> 3) virt users will disable it (as of now, patches exist)
17:04:26 <mjg59> The printer situation seems pretty non-ideal
17:04:40 <mitr> 4) advanced firewall users will disable it (there is a --passthrough, but no way to configure persistently; also, apparently nobody has noticed *815439 beforee today)
17:04:43 <mitr> => who is left?
17:05:13 <gholms> .bug 815439
17:05:16 <zodbot> gholms: Bug 815439 --direct documentation incorrect - https://bugzilla.redhat.com/show_bug.cgi?id=815439
17:05:55 <t8m> mitr, what 2) really means? That it will be disabled by default in the desktop?
17:05:55 <notting> according to the feature page, control-center printer config works, and there's a patch for s-c-printer
17:05:56 <twoerner> mitr: we have a patch for system-config-printer
17:06:10 <sgallagh> How badly are we going to screw ourselves if we follow the contingency plan?
17:06:20 <sgallagh> I know this will cause us to lose zone support
17:06:27 <mitr> notting: the c-c config works, but is not persistent across reboots.
17:06:48 <mitr> 2) we ship it enabled, but what can the users do other than disable it in a GUI?
17:07:23 <t8m> mitr, would it be possible to disable it via a GUI action or will they have to invoke a command-line tool for that?
17:07:56 <mjg59> Digging through the logs from initial approval, and the feature page at the time, the absence of a GUI doesn't seem obviously mentioned
17:07:59 <mitr> We still _can_ ship it enabled, with a relnote about known problems or something (and 3) could perhaps be still handled) - it's mostly about default user experience, and whether a "the first thing I do is disable firewalld" reputation is a risk
17:08:30 <mitr> t8m: Not sure; we had system-config-uservices, I haven't tried it since systemd
17:08:41 <sgallagh> mitr: We seem to have weathered the "first thing I do is disable SELinux" reputation we used to have. So that's maybe not a big issue.
17:09:00 <twoerner> mitr: s-c-services is not working with systemd
17:09:01 <mjg59> So reverting this for F17 - we lose network zones, but do we have any UI for network zones yet?
17:09:02 <t8m> mitr, I'm afraid that the "the first thing I do is disable firewalld" will not be a good thing for the firewalld project reputation - but that is twoerner's call
17:09:33 <mitr> mjg59: Only "edit /etc/sysconfig/network-scripts/ifcfg-*"
17:09:41 <mitr> t8m: right
17:09:44 <mjg59> Ok, so that doesn't seem like the worst thing ever
17:09:50 <mjg59> And IPv6 DHCP breaks again?
17:09:57 <notting> what is involved in fixing printing?
17:10:00 <cmurf> What about the LiveCD lacking a GUI means of disabling, if the LiveCD is going to have firewalld enabled by default?
17:10:20 <pjones> notting: presumably applying the patch twoerner just said he has
17:10:30 <mitr> notting: There is no functionality for persistently changing the config in the D-Bus interface, so possible but non-trivial
17:10:45 <twoerner> pjones: the patch is for system-config-printer for discovery etc
17:10:47 <mjg59> And DHCPv6 was broken in previous releases anyway, right?
17:11:10 <nirik> we can fix dhcpipv6 in iptables easily. (I think there's a working patch too)
17:11:31 <mjg59> Ok
17:11:35 <twoerner> mjg59: DHCPv6 should also not be broken with latest lokkit/system-config-firewall
17:11:36 <notting> mitr: confused - how would printing break after reboot? just b/c mdns won't resolve again?
17:11:48 <mjg59> So what hit do we take with reverting this in F17?
17:12:18 <mitr> notting: mdns/smb etc., unless they are enabled by default in the firewall zone
17:12:38 <twoerner> if your default zone is home, you will have everything you need
17:12:39 <mjg59> Anyone? Anything?
17:12:58 <notting> mitr: so, after you've configured it, it requires the browsing to resolve it again, gotcha
17:13:01 <sgallagh> twoerner: Can you list the downsides to reverting?
17:13:13 <mitr> mjg59: From what I've looked at, it's not a hard dependency anywhere.  the control-center functionality would instead pop up a dialog asking the user to enable services, I'm not sure whether it used the system-config-firewall backend previously
17:13:38 <twoerner> sgallagh: no zones, no persistent libvirt config in case of firewall modifications
17:13:41 <mitr> notting: right - and, fwiw, perhaps we should just enable these things in the default zone and be done with it, anyway.
17:13:50 <notting> mitr: ACK.
17:14:00 <mjg59> Ok
17:14:17 * nirik would like to thank twoerner for all the hard work on this no matter what is decided here. :)
17:14:40 * pknirsch lurks and nods
17:14:41 <sgallagh> Yes, I agree with nirik: you've done quite a herculean job so far twoerner.
17:14:42 <mjg59> #proposal: Enact the contingency plan for Firewalld, disable network zones and revert to static firewall configuration for F17, push the feature to F18 and aim for feature parity
17:14:46 <nirik> personally I would think having it land in f18 with a more solid setup would be good, but it sounds like the part thats listed for f17 feature is all pretty much there now.
17:15:26 <sgallagh> #counter-proposal: Give twoerner until next meeting to have all of the above concerns addressed
17:15:26 <mitr> mjg59: the network zones support in NM will cope, it's just a matter of not publicizing the feature, fwiw
17:15:31 <notting> is the virt issue fixable?
17:15:43 <limburgher> sgallagh:  And if not, then what?
17:15:46 <mitr> notting: patches exist, libvirt is somewhat unhappy about pushing them to f17 this late
17:15:47 <sgallagh> Then revert
17:16:01 <limburgher> sgallagh, zones also?
17:16:06 <mitr> sgallagh: that would be s/twoerner/jpopelka/
17:16:16 <sgallagh> mitr: Sure, sorry.
17:16:17 <mitr> limburgher: see my comment to mjg59 above
17:16:19 <twoerner> notting: the virt issue is fixed now.. patch will be upstream in some seconds
17:16:36 <mjg59> Ok, so how about
17:16:43 <twoerner> sgallagh: next meeting is bad for me.. will be on vacation starting tomorrow
17:16:44 <limburgher> mitr: got it.
17:16:46 <mjg59> #proposal: Enact the contingency plan for Firewalld and revert to static firewall configuration for F17, push the feature to F18 and aim for feature parity
17:17:04 <sgallagh> twoerner: That doesn't inspire terrible confidence in me as to getting this finished :(
17:17:04 * mitr is mildly +1
17:17:24 <sgallagh> mjg59: I think I'm going to have to agree with that. +1
17:17:26 <mjg59> Yeah, I lean +1 - while I really want this feature, I don't think it's quite ready
17:17:32 <limburgher> mjg59: +1
17:17:33 <pjones> I don't really like that plan, but I don't have a better idea
17:17:35 * t8m as well is leaning to +1
17:17:40 <nirik> twoerner: what are your thoughts? I know you have worked hard on this...
17:17:40 <mmaslano> +1
17:17:48 <mitr> I do like the command-line interface, but the breakage is difficult to overlook
17:17:58 <sgallagh> Yeah, I agree. It's a fantastic feature, but I don't feel it's quite ready.
17:17:59 <twoerner> sgallagh: Jiri Popelka is here and taking over
17:18:17 * nirik is also a +1 to the proposal. Lets get it all nice and working NOW in f18/rawhide.
17:18:30 <mjg59> twoerner: We're at the point where it really should already be finished in F17, but right now while there's definite advantages to it, it also seems to be a functional regression over F16
17:18:36 <twoerner> nirik: I think it is in a usable state
17:19:09 <notting> so, to get it all working to snuff per the reported use cases, we'd have to: 1) change the default zone config to allow mdns/smb browsing 2) force in a late libvirt change
17:19:13 <twoerner> nirik: zones could solve a lot of problems of users with different connections
17:19:34 <mjg59> twoerner: But zones are currently not exposed in the NM UI?
17:19:36 <nirik> I agree it's a great feature, it just seems so late for this cycle to get all the issues worked out.
17:19:47 <twoerner> mjg59: no
17:19:58 <pjones> mjg59: my biggest objection to your proposal is that while it's right by the letter of the policy, it seems to be more strict than we've really been in the past.  But that's obviously just my impression with no real data.
17:19:59 <twoerner> mjg59: but to the fireall-applet
17:20:07 <notting> twoerner: if we defer to f18, are we going to keep with the plan of removing s-c-firewall then and just do a flag day?
17:20:48 <mjg59> notting: I'd argue we should just drop it in rawhide now?
17:20:50 <twoerner> notting: there needs to be some time for users to migrate
17:21:40 <mitr> twoerner: time users spend to migrate is not necessarily related to Fedora release process (... as long as they have something to migrate _to_, which doesn't seem to be the case for expert iptables users right now)
17:22:10 <twoerner> expert iptabels users are using static firewalls
17:22:15 <twoerner> for now
17:22:18 <pjones> mitr: it isn't?  expert users can't turn off firewalld and use their old tables?
17:22:34 <mitr> pjones: Sure... but then the meaning of "flag day" is vague
17:23:34 <nirik> so, sounds like we would like to revert for f17?
17:23:37 <mitr> notting: I suppose deferring to f18 would mean deferring the flag day to f19 as well because we can't be sure to notice all regressions in beta
17:23:49 <nirik> whats involved in doing that? and who has that as action items?
17:23:53 <notting> mitr: i'm fine with keeping a flag day.
17:24:03 <mjg59> mitr: If we make the transition at the start of f18 (or even just do it now in rawhide) then we have the entire cycle to notice that
17:24:08 <pjones> yeah, deferring would mean pushing the flag-day along
17:24:10 <notting> i'm a mild +1 to revert
17:24:22 <twoerner> the question here is what needs to get reverted in that case?
17:24:34 <notting> nirik: revert is swapping some packages in comps, and ... i believe swapping the state of the iptables service files?
17:24:35 <twoerner> every change for zones and firewalld?
17:24:35 <mitr> mjg59: I'm... not confident that iptables users will be testing this unles forced to
17:24:38 * notting looks at twoerner
17:24:42 <pjones> twoerner: honestly - probably comps?
17:24:57 <pjones> what notting said
17:24:58 <limburgher> Anything in anaconda or preupgrade?
17:25:07 <nirik> if we can revert the default, but still provide a way for interested people to install and test/use it, that would be great!
17:25:08 <mitr> AFAICS comps, systemd unit files for firewalld/iptables (?), and I'm not sure about control-center printer support
17:25:10 <twoerner> notting: right
17:25:18 <twoerner> limburgher: no
17:25:26 <limburgher> Right, it's best if the packages stay in.
17:25:49 <mitr> Also, there's the dhcpv6 config for iptables
17:25:51 <twoerner> control-center printer support never was working without firewalld
17:25:59 <twoerner> as far as I know
17:26:01 <notting> mitr: twoerner said that was fixed in the latest
17:26:03 <pjones> limburgher: anaconda just uses comps
17:26:06 <mjg59> Well that's unfortunate
17:26:53 <mitr> twoerner: Great, one leess thing to revert - the code seems to handle firewalld missing; and if firewalld is installed, it will be transparently used.
17:27:01 <mjg59> Do we have any alternative to reverting? Other than the absence of a UI, what are we going to be missing? Is there any way to fix printing?
17:27:28 <notting> so, http://fpaste.org/wC6N/ for iptables, and reverting edb2eb2ef86a63cd86043c77bc808db65cf0b40f in comps
17:27:59 <mitr> mjg59: 1) relax default firewall to let printers in, 2) push through the libvirt changes
17:28:06 <twoerner> mjg59: if there would be some startup code to enable the needed firewall setting
17:28:12 <pjones> mitr: ew ew ew
17:28:28 <mitr> mjg59: Also, zones are... there but not very visible
17:28:39 <mjg59> mitr: If we're going to relax the default firewall rules then there's probably other changes we should make as well
17:29:01 <mjg59> And it's probably the kind of change that would result in screaming
17:29:06 <mjg59> Not that I'm adverse to changes that result in screaming
17:29:07 <twoerner> mjg59: what changes are you thinking of?
17:29:25 <mjg59> twoerner: If we're letting in mdns then we should also talk about upnp
17:29:43 <mjg59> And does Salut/Bonjour need anything other than open mdns?
17:29:47 <mitr> mjg59: right, both 1) and 2) are a little late in beta
17:29:57 <mjg59> Yeah
17:30:17 <mjg59> Well, in that case I guess we probably go with reverting for F17 and concentrate on F18
17:30:25 <twoerner> mitr: both 1) and 2) are simple fixes.. use "home" as the default zone
17:30:37 <mjg59> twoerner: It's the policy change, not the technical side of it
17:30:43 <notting> twoerner: home allows everything?
17:30:54 <twoerner> notting: a lot of things for desktop use
17:31:06 <mitr> notting: ssh ipp-client mdns samba-client dhcpv6-client
17:31:24 <notting> how does that fix libvirt?
17:31:37 <twoerner> notting: ssh, ipp-client, mdns, samba-client and dhcpv6-client
17:32:29 <twoerner> notting: libvirt needs 2 new patches.. one to get dbus working in libvirt and the other to add firewalld suppport
17:33:13 <twoerner> notting: the dbus patch is already upstream (from Daniel P. Berrange)
17:33:24 * gholms rings the 30 minute bell
17:33:43 <twoerner> notting: the other one will be as soon as I have time to send it with TAB to space migration
17:34:10 <notting> still, a little late for that.
17:34:22 <notting> mjg59: what's the tally at the moment? anyone want to change?
17:34:33 <mjg59> +8 to revert, +9 if pjones was
17:35:04 <pjones> I think I'm sticking with +0; it seems awfully much like we're punishing twoerner for following the feature process.
17:35:06 <sgallagh> I'm wavering at +0 right now
17:35:39 <mjg59> Anyone want to change?
17:35:42 <mitr> pjones: given the 6 months pause in commits at the time of original feature proposal, I'm not sure about that
17:35:52 <adamw> note, we have TC1 scheduled today, so if we decide to revert we'll have a reverted build very soon to figure out what needs fixing.
17:35:53 * t8m agrees with pjones although I still think we should rather be more strict with other disruptive features as well.
17:36:04 <mitr> (not that I don't have projects with a larger pause in commits :) )
17:36:05 <t8m> mitr, and that's and argument too
17:36:07 <nirik> I think twoerner has done great work, but I think this will be much nicer in f18. ;)
17:36:11 <mjg59> Ok
17:36:15 <adamw> i'm not sure it's right to look at delaying a feature as 'punishing the feature's developer', tbh.
17:36:32 <adamw> it seems an unnecessarily negative/personalized way of considering things.
17:36:39 <t8m> yeah
17:36:45 <mjg59> #agreed Feature should be deferred to F18, appropriate changes made to F17 (+7, -0)
17:36:54 <pjones> adamw: you can look at it however you like.
17:37:08 <notting> twoerner: so, just the comps change and the iptables packagechange?
17:37:12 <mjg59> twoerner: Sorry it didn't work out for F17 - I'm really looking forward to this
17:37:17 <twoerner> notting: yes
17:37:21 <notting> twoerner: i can do comps, you want to do the iptables package?
17:37:41 <twoerner> notting: ok
17:37:50 <mjg59> #topic #839     Proposal for revitalizing the packager sponsorship model
17:37:55 <mjg59> .fesco 839
17:37:56 <zodbot> mjg59: #839 (Proposal for revitalizing the packager sponsorship model) – FESCo - https://fedorahosted.org/fesco/ticket/839
17:38:56 <mjg59> tibbs: Around?
17:39:03 <tibbs> Yeah.
17:39:04 <sgallagh> I'm in favor of the "diverge sponsers from PP" and make anyone who wants to be one a sponsor proposal.
17:39:05 <mmaslano> the draft proposal looks very good to me
17:39:12 <mjg59> Yes, this seems broadly sensible
17:39:16 <tibbs> I was just looking for comments; obviously there are plenty of tunables.
17:39:22 <mjg59> I think bringing this up on devel@ would be great
17:39:24 * nirik likes the proposal in general.
17:39:46 <notting> is the sponsor -> implicit in FAS?
17:39:47 <tibbs> Yes, it needs public discussion but I didn't want to waste my time in flame wars of there was little chance of getting it approved here.
17:39:54 <tibbs> It is not.
17:39:57 <t8m> 1. the current sponsors would have to be made PPs automatically if these roless will be disconnected
17:40:10 <tibbs> All current sponsors are provenpackagers.
17:40:12 <notting> tibbs: so if i've been forgetting to add sponsors to PP, it's been accidentally severed
17:40:38 <tibbs> Ah, correct.  Yes, I've assumed that whoever has been pushing those buttons have been doing both things.
17:40:44 <limburgher> I like it.
17:40:47 <mitr> tibbs: The current dependency on provenpackager implies experience with "wide variety of packages"; new criteria don't require anything like that, which seems to open a path for "ruby SIG sponsor etc".  Is that intentional?
17:40:52 * nirik has tried to do it, but may have failed at some point.
17:41:20 <tibbs> mitr: This isn't about provenpackager, except that we'd no longer have sponsor imply it.
17:41:33 <nirik> provenpackagers and sponsors are different things, we simply granted pp to sponsors in the past as a way to make sure they could change their sponsorees packages.
17:41:35 <tibbs> I'm trying not to get into what the criteria for being made provenpackager would be.
17:41:40 <sgallagh> tibbs: I think mitr is asking whether part of the goal here is to have targeted sponsors
17:41:43 <mitr> tibbs: I was thinking about the "area-specific sponsor" aspect.
17:41:47 <sgallagh> i.e. Sponsors who specialize in PERL packages
17:42:03 <tibbs> I made no consideration of that idea.
17:42:14 <tibbs> I don't honestly see the point, honestly.
17:42:14 <mmaslano> we already have some sponsors who are specialized in one area and they are sponsoring people in the area
17:42:17 <sgallagh> Because with the current assumption of provenpackager, it implies a wider general knowledge
17:42:25 <mitr> (I'm thinking we eventually want area-specific provenpackagers as well - and in both cases let's hope we an do it informally without adding infrastructure/bureaucracy)
17:42:46 <sgallagh> mitr: To some extent, I think we already have that.
17:42:46 <tibbs> Again, trying to avoid staying out of provenpackager here.
17:42:53 <limburgher> mmaslano:  Which is great.
17:42:59 <mitr> sgallagh: yeah, violating the formal rules :)
17:43:01 * nirik doesn't see what change having area specific would make to this. It would allow them, just as we kind of have them now. ;)
17:43:03 <tibbs> And trying not to add things like domain-specificity to sponsors, when we have no infrastructure that could enforce that.
17:43:12 <notting> tibbs: how does one quantify "high-quality, non-trivial package reveiws"? i suppose if it's up to sponsors, it's up to them
17:43:18 <limburgher> tibbs:  Nor should we, really, IMHO.
17:43:27 <limburgher> notting: As it is now.
17:43:28 <mitr> tibbs: The thing is, the criteria as stated lead to accepting area-specific sponsors.
17:43:35 <sgallagh> mitr: Well, we don't have any other way to deal with things since bodhi won't let you create multi-package updates without provenpackager (or being a maintainer of all the affected packages)
17:43:37 <t8m> would it be possible to easily change the koji/git/bodhi rules so sponsors would be able to modify sponsorees' packages without pp?
17:43:39 <tibbs> It is difficult to quantify pretty much anything about reviews.
17:43:55 <mitr> Sure
17:43:56 <notting> t8m: given the sponsor -> sponsoree mapping isn't necessarily tracked anywhere... don't think so
17:43:58 <nirik> t8m: thats one thing this proposal is talking about doing.
17:44:06 <tibbs> It would be possible.  I looked briefly into it but it's a bit involved.
17:44:13 <t8m> notting, I thought it is tracked in FAS
17:44:25 <tibbs> That is the one remaining technical issue that needs working out before this could proceed (if approved).
17:44:29 <nirik> it's tracked in the fas db, but not exposed very well
17:44:30 <limburgher> it is in FAS.
17:44:41 <mitr> tibbs: Either way is fine with me, really - perhaps just clarify whether we want area-specific or general sponsors for the criteria ?
17:44:48 <tibbs> The problem is that ACLs aren't generated from FAS, they're generated from pkgdb.
17:45:13 <tibbs> I'm not sure what an area-specific sponsor would be, and honestly wouldn't want to define things that narrowly.
17:45:30 <mjg59> Any more feedback on this for now, or should we let it get discussed on devel?
17:45:32 <tibbs> Once you get sponsorship status, you have it.  Whether you choose to restrict yourself would be your decision.
17:45:32 <nirik> proposal: have discussion on devel list, adjust per feedback and vote on next week or whenever it's ready?
17:45:44 <mitr> +1
17:45:44 <sgallagh> tibbs: I agree, I think you misunderstood.
17:45:52 <limburgher> nirik: +1
17:45:56 <mjg59> Not sure we even need to vote on this
17:45:59 <sgallagh> tibbs: It would be relaxing the rules to become a sponsor such that area-specific is possible
17:46:14 <mjg59> Anyone think this is a bad idea?
17:46:16 <sgallagh> #proposal: Accept tibbs proposal as-is
17:46:21 <t8m> nirik, +1
17:46:21 <sgallagh> +1
17:46:29 <limburgher> sgallagh: I think that would occur organically.
17:46:35 <mitr> mjg59: The meetings and minimum requirements are a gamble, but worth the risk I think.
17:46:45 <sgallagh> limburgher: Yes. I'm not trying to force it.
17:46:47 <tibbs> My proposal is pretty relaxed as is, I think, with an eye towards making it easy and mostly self-governing.
17:46:50 <nirik> I'd like to see some more details worked out... and the tunables adjusted before we approve it.
17:46:53 <pjones> sgallagh: -1
17:47:02 <pjones> sgallagh: as smart as we are, having some broad discussion would be good
17:47:03 <tibbs> But my office has been invaded by electricians now, so I have to run.  Thanks for the discussion.
17:47:04 <notting> how does this handle things like fesco-sponsored comaintainers?
17:47:08 <mjg59> #agreed Raise proposal on devel@, bring it back to fesco once there's been wider discussion
17:47:14 <sgallagh> pjones: Fair enough
17:47:32 <mjg59> #topic #830     define requirements for secondary arch promotion
17:47:35 <mjg59> .fesco 830
17:47:36 <zodbot> mjg59: #830 (define requirements for secondary arch promotion) – FESCo - https://fedorahosted.org/fesco/ticket/830
17:47:37 * jonmasters is magically summoned. Good afternoon, folks
17:47:51 * bconoboy appears in a puff of logic
17:47:59 <jonmasters> :)
17:48:16 <sgallagh> Anyone else just hear a "foop" sound?
17:48:44 <mjg59> So there's been some feedback on devel - much of it has been asking for quantitative details that I don't think are appropriate, but there was some input from dgilmore that's led me to change the mention of releng/infrastructure and bconoboy expressed unhappiness with the phrasing of the Anaconda requirements so I've reworded those as well
17:49:00 <nirik> whats the link to the proposal again?
17:49:02 <limburgher> Oof!
17:49:08 <mjg59> http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements_%28Draft%29
17:49:13 <nirik> thanks
17:49:26 * jonmasters also asked for clarification of things like "sufficient developer resources" that is still missing
17:49:46 <jonmasters> (does that mean hardware, people, etc. - I had a few things in my email, not just this one)
17:49:51 <mjg59> jonmasters asked whether we wanted to impose any requirements about integration of ports into documentation
17:50:04 <jonmasters> ...or the website, etc.
17:50:12 <mjg59> jonmasters: I thought we covered that in the thread? I don't think it can really be clarified
17:50:28 <mjg59> The idea is that if you're slowing down development of the port then the developer resources aren't sufficient
17:50:31 <jonmasters> mjg59: well, even unofficially. Were you meaning to imply people or machines as "resources"?
17:50:36 <mjg59> Yes
17:50:42 <jonmasters> :)
17:50:48 <jonmasters> *or* :)
17:50:56 <bconoboy> examples and clarification, are evidently not appropriate to this document.
17:51:02 <pjones> jonmasters: yeah, you should totally add a documentation requirement on the wiki
17:51:37 <jonmasters> that's ok. If examples and clarification are not appropriate, can we please explicitly record the fact that we requested these and were told they were not relevant? I would like this noted for future reference :)
17:51:48 <pjones> that's in the logs plenty of times.
17:51:59 <jonmasters> good, just making sure it's logged again
17:52:01 <mjg59> The examples and clarifications that have been asked for were things that *I* didn't think were appropriate
17:52:11 <pjones> though I don't think anybody has said they're /irrelevant/.
17:52:11 <nirik> yeah, perhaps "Arch specific docs (wiki, docs.fp.o) must be updated to include the new arch, and have sufficent resources to keep them up to date" ?
17:52:21 <mjg59> That doesn't mean that examples and clarifications are inherently inappropriate, or even that the ones asked for were inappropriate
17:52:22 <bconoboy> mjg59:I've taken the silence of other fesco members on this point to mean agreement with you
17:52:26 <mitr> jonmasters: I think 1) "the port" should be usable enough for individual package maintainers to fix their bugs (which may be arm-specific), and 2) if a developer needs an ARM environment to reproduce/fix a bug, there needs to be a way to get it (this may be qemu, ssh, or perhaps physical for important driver developers - this would be an unusual case)
17:52:30 <jonmasters> nirik: problem is the whole Fedora Project website is very x86 assuming at the moment
17:52:51 <nirik> how can we clarify "sufficent developer resources"? "You must have 26 developers, no more, no less"?
17:53:04 <pjones> jonmasters: right.  I don't think we'd be asking the SA to e.g. rewrite the downloads page to integrate the port
17:53:19 <nirik> jonmasters: yeah, but how much change is there really? install is different... but software should all be the same right?
17:53:20 <jonmasters> mitr: yea, we'll have hardware provisioning in due course - need to work out the legals/other stuff, but we will. If my idea for JTAG provisioning works out, we'll even be able to give systems safe against firmware tampering ;)
17:53:21 <mitr> nirik: One of the points of PA is "everybody needs to care", so I don't really like the idea of pushing all kinds of work on the ARM team
17:53:44 <pjones> mitr: which is one of the reasons we don't want to quantify that
17:53:51 <nirik> please do propose alternate docs wording. ;) That was just off the top of my head.
17:54:04 <mitr> pjones: This was reacting to "have sufficient resources to keep [the docs] uptodate"
17:54:09 <nirik> I didn't say anything about the arm team doing all that work.
17:54:20 <mjg59> Yes, really the reason I haven't changed anything about the developer resources section is because I haven't figured out better wording myself and nobody's proposed better wording
17:54:28 <pjones> mitr: I assume he means the docs team has to have sufficient resources.
17:54:34 <mitr> oh, right.  sorry
17:54:35 <nirik> resources there might include people available to answer questions from the docs and websites teams.
17:54:50 <pjones> right
17:54:53 <nirik> "hey, how do I install this on arm, I'm updating section foo of the install guide"
17:55:15 * jonmasters is mostly concerned if there's a RH/other staffing impact. For example, if (theoretically) we would need X number of paid developers just working on ARM to be PA, that would be something I would need to know asap for future planning.
17:55:16 <pjones> right, same thing we have for various things within the PA as it currently stands.
17:55:34 <mjg59> jonmasters: Nobody's ever going to put a hard number on this
17:55:42 <pjones> jonmasters: that's something you know better than us.  we're setting the expectation, you're coming up with a plan to meet it.
17:56:05 <jwb> personally, i'd expect to have someone named as the ARM kernel maintainer
17:56:09 <bconoboy> jonmasters: As I understand it, fesco is backing the Do Everything it takes to be Primary, then talk to us approach- which means it's an exercise left to the SA to figure out how many peple are neede.d
17:56:22 <jonmasters> mjg59: right, that's actually ok. I just want it very clear for future reference when we come back again that we did ask this question. So, if hard numbers were expected next time, we'd just point to this discussion.
17:56:23 <mjg59> jonmasters: If the current developer resources on the ARM port are able to keep up with all the other primary architectures then that's absolutely fine and you don't need any more
17:56:23 <jwb> whether it's a paid position, or someone in the community is irrelevant
17:56:27 <pjones> bconoboy: good lord, no
17:56:38 <pjones> bconoboy: not "do things and *then* talk to us".  That's completely wrong.
17:56:42 <nirik> I'd like to note that we haven't ever done this before either, so there will for sure be give and take in the process...
17:57:09 <nirik> and yes, continued communication is vital.
17:57:13 <bconoboy> pjones: I mean, with some sort of communication throughout, but basically no hard numbers- the numebr will be known when you're done
17:57:26 <mjg59> ARM's going to have it hard in some ways because it's the first and we're going to find bugs in the entire process, but probably easy in other ways because we're likely to give more slack to deal with the fact that this is as novel for us
17:57:34 <jonmasters> pjones: bconoboy isn't saying we'll go off in a vacuum :) We do read the feedback. And yes, we'll start using #fedora-meeting soon or something :)
17:57:39 <nirik> mjg59: +1
17:57:45 <pjones> bconoboy: we've got a list of fairly vague criteria that apply generally to anybody wanting to be a PA.  You guys come up with a set of plans on how to meet that goal.  In the mean time there's a pile of interaction that needs to happen
17:58:04 <mjg59> bconoboy: Do you think that the ARM port has enough developers on it that it's unlikely to delay development of Fedora as a whole?
17:58:22 <jonmasters> mjg59: I look forward to the future OpenRISC PA push with much interest :)
17:59:19 <jonmasters> mjg59: I don't think we have insufficient developers. It is clear there is a need to get certain others hardware. For example, Lennart expressed a lot of interest in getting a free ARM board and we're sending him one. We'll do the same for certain other critpath developers, and we'll get general access setup too.
17:59:36 <mjg59> jonmasters: Ok, so I suspect that you're going to have no problems meeting that requirement
17:59:46 <bconoboy> mjg59: Today? No.  More of the community does need to be engaged.  We're talking process
17:59:52 <jonmasters> At least ARM hardware is cheap. So, we're happy to send shiny goodies to a few folks where we have funds to do so
17:59:54 <nirik> so, perhaps for the docs point: "A dialog should exist with the documentation and websites teams on work needed to add the arch. Resources should be available to assist those teams in getting the arch added"
18:00:52 <mjg59> Anyone think we need anything stronger for documentation/website requirements?
18:00:58 <mitr> nirik: that's nice
18:01:11 <t8m> nope, I'm fine with the draft as is
18:01:11 <mjg59> (I'm fine with nirik's suggestion)
18:01:12 <pjones> As much as I dislike using the word "dialog" as a noun, that's fine.
18:01:18 <limburgher> Nothing concrete.  If FESCO's evaluating the candidate, we'll evaluate.
18:01:42 <mjg59> Ok, so subject to adding some language about docs/website, do we want any other changes made?
18:01:44 <bconoboy> pjones: Right, criteria are very vague.  Is this what fesco is going to pass?  If so we'll work with it, but I'm looking for more information on how to work with it.  Is updating the existing proposal and having it voted on how it's going to work? Or is there a different process?
18:02:50 * mitr is not that worried about the process :)
18:02:55 <nirik> I'd personally like to see us approve this, then keep a open dialog. If you run into parts you can't meet or don't make sense, we should revise it then...
18:03:09 <jonmasters> ok, so it's a fluid, ongoing process?
18:03:13 <bconoboy> fesco isn't worried about the process because fesco is the process :-P
18:03:23 <limburgher> nirik: Yes, and that will help put legs on getting the whole thing going.
18:03:39 <mitr> What nirik said - let's keep talking about things that can/can't work, and at one time we'll need to decide on a yes/no.
18:03:40 <t8m> nirik, +1
18:03:43 <jonmasters> Can we propose that? Rather than being hard-and-fast, these are the initial promotion reqs and we'll specifically state for the record that it's going to be a collaborative ongoing process to figure out the final "requirements"?
18:04:02 * nirik is fine with that. In fact i think the page says that already.
18:04:27 <jonmasters> right, but I'd like you guys to say that's what you want, so we don't consider that page as gospel for everything, for all time
18:04:42 <mjg59> jonmasters: I think the best way of thinking about it is that the only real requirement for something to be promoted is that nobody who matters is objecting
18:04:58 <nirik> would weekly status updates help us? or be a burden on us/arm team?
18:04:59 <jonmasters> mjg59: maybe that's a criteria then ;)
18:05:07 <mjg59> jonmasters: This document provides you with a bunch of indications as to whether anyone is likely to object
18:05:13 <jonmasters> nirik: how about we do at least monthly status reports for you?
18:05:15 <mjg59> jonmasters: Well, it does say that already
18:05:17 <pjones> This list represents the areas we believe need to be addressed.  How you plan on addressing them is up to you; we don't want to specify that.
18:05:29 <jonmasters> we'd like to get in the habit of doing that anyway
18:05:42 <jonmasters> (to foster broader engagement)
18:06:02 <pjones> So if we approve this, I would expect the next steps to be for you guys to come up with implementation plans for us to review and make sure *we* believe actually sufficiently cover the things on the list.
18:06:10 <jonmasters> ok
18:06:28 <nirik> yeah, status reports would be nice, that way we know whats going on and if there are red flags for anyone.
18:06:31 <pjones> which, I mean, you could totally start on even without this being approved to be honest.
18:06:46 <mjg59> Ok, so I've added "The port should work with the documentation and website teams to determine the work needed to add the architecture. Resources should be available to assist those teams in adding the architecture to public resources."
18:06:53 <bconoboy> pjones: Do you want this proposal as a feature page?
18:06:56 <mitr> Weekly is unnecessarily frequent, I think...
18:07:03 <jonmasters> note, I'm well aware F18 is looking unrealistic. We want to do this right, not in a rush. We need to have this dialog ongoing, but we can time things when appropriate. The main blocker is getting build hardware up in PHX, which is looking like it's going to be August at this rate.
18:07:08 <mitr> bconoboy: Isn't there already one? :)
18:07:19 <pjones> bconoboy: I would expect that sometime near the end of the process, we get a Feature when we're actually planning to switch it to a PA
18:07:20 <nirik> yeah, I don't want to burden us or arm with too useless status reports.
18:07:26 <pjones> bconoboy: I don't think the stuff in the middle needs to be that
18:07:28 <bconoboy> mitr: Sure is- I imagine we'll simply update it to reflect the 10-point list.
18:07:38 <pjones> bconoboy: there's no need for that level of formality.
18:07:59 <jonmasters> nirik: ok, we'll aim to send a nice monthly summary out to devel to make sure everyone knows what we're working on, and what the main issues are at any one time
18:08:09 <mjg59> As I said on devel, the best way to make sure that you meet these things is to make it very clear to the developer population what's going on
18:08:19 <jonmasters> We do also need to improve the accessibility for new developers - we're working on all of this
18:08:35 <mjg59> Because that way you're going to get earlier feedback, even from people who aren't actively involved in your port
18:08:42 <jonmasters> right
18:08:49 <mjg59> And the more feedback you get, the less likely it is that someone will object
18:08:50 <nirik> yeah, doing irc meetings in fedora-meeting would be a good step too, IMHO.
18:09:13 <mjg59> So yes, having your meetings be in places where people can read over your decision making process without having to take the time out to attend the meeting itself is a great thing
18:09:18 <jonmasters> we'll do a test run of using fedora-meeting and see how it goes
18:09:35 <mjg59> It's not a requirement, it just means it's much more likely that you'll make everyone happy
18:09:42 <jonmasters> If it turns into "Kevin's forum for hating on ARM" I'll be wanting to rethink that
18:09:56 <mjg59> If people are disrupting meetings then that's something for the cwg
18:09:56 <pjones> it works pretty well for everybody else in fedora, and it's basically the same thing all of debian does, so you probably ought to be able to make it work.
18:10:21 <jonmasters> mjg59: well, that was my main resistance. But, yea, we'll try fedora-meeting this week
18:10:42 <mjg59> jonmasters: Seriously, it is unacceptable for people to behave in a way that disrupts the work of others
18:10:48 * nirik nods.
18:11:03 <mjg59> If it happens then let us know. We'll make sure it doesn't again.
18:11:04 <nirik> if folks disrupt meetings, please let us know.
18:11:20 <jonmasters> ok, then, we'll switch to fedora-meeting from this week
18:11:23 <mjg59> Great
18:11:40 <mjg59> Also, blog more
18:11:58 <mjg59> People will pay more attention to a project if they hear things about it
18:12:00 <pjones> jonmasters: in reality most of the people that would be disruptive just won't notice the meeting is happening and won't show up
18:12:02 <jonmasters> yea, I've been meaning to. Sadly I spent a lot of last week tracking down bugs like the audit problem
18:12:49 <jonmasters> mjg59: FWIW I'm giving a presentation on Fedora ARM at LinuxCon Japan, and at Red Hat Summit, and a few other events in the next two months. I'll set aside time to get a dedicated blog up too.
18:12:53 <mjg59> Ok. Do we want to vote on these and take the draft marker off?
18:13:01 <limburgher> Another advantage to IRC meeting is that interested parties can lurk more easily. :)
18:13:34 <pjones> proposal: we accept these criteria now, with the expectation that the SA will come up with plans to meet them.
18:13:41 <mjg59> +1
18:13:45 <notting> +1
18:13:53 <mitr> +1
18:13:55 * pjones +1
18:13:56 <sgallagh> +1
18:13:59 <nirik> +1
18:14:05 <limburgher> +1
18:14:09 <jonmasters> limburgher: yea, sometimes we've benefited with the phone meetings from a small group that e.g. all have NDAs with hardware vendors, but we can just have separate meetings to discuss super-secret stuff around which vendors will have servers for us in PHX.
18:14:30 <limburgher> jonmasters: Exactly.  Open by default. :)
18:14:38 <mjg59> mmaslano? t8m?
18:14:40 <jonmasters> I'm not opposed :)
18:14:48 <mmaslano> +1
18:14:48 <t8m> +1
18:14:51 <mjg59> Ok
18:15:16 <pjones> the motion passes with unanimity.
18:15:20 <mjg59> #agreed Secondary architecture promotion requirements are approved, we'll continue followup discussions with secondary architectures over plans to implement them
18:15:26 <jonmasters> let's set an expectation that we'll get monthly status reports on devel@ during the first week of each month also, for the ARM specific case
18:15:37 <mjg59> jonmasters: Sounds good to me. We'll see how that goes.
18:15:43 * bconoboy signs jonmasters up for that
18:15:43 <pjones> jonmasters: you're free to do status reports as often as you like.
18:15:57 <jwb> preferrably where "like" is not "never"
18:15:58 <jwb> :)
18:16:10 * jonmasters does want to engage more. I'm suffering a little from not scaling myself as well as I'd like. Perhaps I need to drink even more hyperscale koolaid ;)
18:16:12 <mjg59> jonmasters: bconoboy: Thanks for your patience on this. Your input has been valuable.
18:16:34 <jonmasters> hey, thanks guys
18:17:02 <mjg59> #topic Next week's chair
18:17:03 <bconoboy> mjg59: thanks again for putting together the page- we'll use it as a template to scope our planning when we're not talking directly to you all.
18:17:07 <nirik> best of luck to arm. Looking forward to it. ;)
18:17:49 <mmaslano> fyi I won't attend next and also the next week
18:17:50 <nirik> I will be out next week, so I cannot chair.
18:18:01 <mjg59> Anyone else going to be missing next week?
18:18:03 <jonmasters> nirik: you think that's fun, wait until we have some 64-bit ARM goodies to share ;)
18:18:19 <limburgher> Not that I know of.
18:18:29 <mjg59> Should still have enough for quorum, then
18:18:35 <mjg59> Anyone willing to volunteer?
18:18:39 <notting> i will have to leave ~ 2:15, so i'm not the best choice. will be here, though
18:18:50 <limburgher> People hate when I chair. . .
18:18:57 <mjg59> limburgher: Perfect. You can chair.
18:19:02 <limburgher> D'oh!
18:19:04 <limburgher> Ok.
18:19:11 <mjg59> #agreed limburgher chairs next week
18:19:15 <mjg59> #topic Open Floor
18:19:16 <gholms> Heh
18:19:19 <mjg59> Anyone got anything?
18:19:20 <t8m> mjg59, I might not be able to attend next week as well
18:19:41 <mjg59> t8m: Ok - should still be just about ok, but if anyone else vanishes we may not make quorum
18:19:47 <mjg59> We'll see how it goes
18:20:03 <mitr> Do we want #840 today or next week?
18:20:03 <mjg59> Probably best to assume we'll have a meeting just in case any post-beta disasters arise
18:20:29 <mjg59> mitr: It was opened 98 minutes ago, I think we leave it
18:21:24 <mjg59> Ok, I'll close out in a minute if nobody has anything more
18:22:00 <mjg59> #endmeeting