17:00:08 #startmeeting FESCO (2012-04-23) 17:00:08 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:08 #meetingname fesco 17:00:08 #chair notting nirik mjg59 mmaslano t8m pjones sgallagh mitr limburgher 17:00:08 #topic init process 17:00:08 The meeting name has been set to 'fesco' 17:00:08 Current chairs: limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m 17:00:16 Ok, who's here this week? 17:00:17 hello. 17:00:20 * nirik waves 17:00:22 hi 17:00:26 Hi 17:00:41 I'll note that I will in fact NOT be here next week. ;) 17:00:45 * limburgher here 17:01:24 hello 17:01:24 * notting is here 17:01:37 mitr: Around? 17:01:41 Hello 17:01:47 Excellent, full house 17:02:00 So, let's get going 17:02:02 * sgallagh reveals a straight flush 17:02:10 I'm going to propose we leave the secondary architecture stuff to the end? 17:02:18 agree 17:02:20 Sure 17:02:21 yeah 17:02:26 Ok 17:02:29 #topic #829 New proven packagers request: Pavel Alexeev (hubbitus) .fesco 829 17:02:34 mjg59: I dropped the ball here. 17:02:36 .fesco 829 17:02:37 we approved this last time. 17:02:37 mjg59: #829 (New proven packagers request: Pavel Alexeev (hubbitus)) – FESCo - https://fedorahosted.org/fesco/ticket/829 17:02:42 Yeah, thought so 17:02:43 * nirik will go fix it. 17:02:46 Thanks! 17:02:52 That's a really easy one 17:03:01 #topic #838 https://fedoraproject.org/wiki/Features/firewalld-default status 17:03:06 .fesco 838 17:03:07 mjg59: #838 (https://fedoraproject.org/wiki/Features/firewalld-default status) – FESCo - https://fedorahosted.org/fesco/ticket/838 17:03:25 concern is no GUI tool? 17:03:29 twoerner: We're past beta and this doesn't seem feature complete yet? 17:03:33 I have taken a more detailed look today 17:03:34 notting: Yup 17:03:42 1) the basic use cases work, and the UI is much nicer than iptables 17:03:46 I really don't like all the work on this past beta 17:03:50 mjg59: the features are there in my opinion 17:03:51 i could have sworn that 'no gui tool' was explicilty in the feature when we approved it 17:04:00 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 notting: yeah, that rings a bell with me as well 17:04:08 3) virt users will disable it (as of now, patches exist) 17:04:26 The printer situation seems pretty non-ideal 17:04:40 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 => who is left? 17:05:13 .bug 815439 17:05:16 gholms: Bug 815439 --direct documentation incorrect - https://bugzilla.redhat.com/show_bug.cgi?id=815439 17:05:55 mitr, what 2) really means? That it will be disabled by default in the desktop? 17:05:55 according to the feature page, control-center printer config works, and there's a patch for s-c-printer 17:05:56 mitr: we have a patch for system-config-printer 17:06:10 How badly are we going to screw ourselves if we follow the contingency plan? 17:06:20 I know this will cause us to lose zone support 17:06:27 notting: the c-c config works, but is not persistent across reboots. 17:06:48 2) we ship it enabled, but what can the users do other than disable it in a GUI? 17:07:23 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 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 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 t8m: Not sure; we had system-config-uservices, I haven't tried it since systemd 17:08:41 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 mitr: s-c-services is not working with systemd 17:09:01 So reverting this for F17 - we lose network zones, but do we have any UI for network zones yet? 17:09:02 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 mjg59: Only "edit /etc/sysconfig/network-scripts/ifcfg-*" 17:09:41 t8m: right 17:09:44 Ok, so that doesn't seem like the worst thing ever 17:09:50 And IPv6 DHCP breaks again? 17:09:57 what is involved in fixing printing? 17:10:00 What about the LiveCD lacking a GUI means of disabling, if the LiveCD is going to have firewalld enabled by default? 17:10:20 notting: presumably applying the patch twoerner just said he has 17:10:30 notting: There is no functionality for persistently changing the config in the D-Bus interface, so possible but non-trivial 17:10:45 pjones: the patch is for system-config-printer for discovery etc 17:10:47 And DHCPv6 was broken in previous releases anyway, right? 17:11:10 we can fix dhcpipv6 in iptables easily. (I think there's a working patch too) 17:11:31 Ok 17:11:35 mjg59: DHCPv6 should also not be broken with latest lokkit/system-config-firewall 17:11:36 mitr: confused - how would printing break after reboot? just b/c mdns won't resolve again? 17:11:48 So what hit do we take with reverting this in F17? 17:12:18 notting: mdns/smb etc., unless they are enabled by default in the firewall zone 17:12:38 if your default zone is home, you will have everything you need 17:12:39 Anyone? Anything? 17:12:58 mitr: so, after you've configured it, it requires the browsing to resolve it again, gotcha 17:13:01 twoerner: Can you list the downsides to reverting? 17:13:13 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 sgallagh: no zones, no persistent libvirt config in case of firewall modifications 17:13:41 notting: right - and, fwiw, perhaps we should just enable these things in the default zone and be done with it, anyway. 17:13:50 mitr: ACK. 17:14:00 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 Yes, I agree with nirik: you've done quite a herculean job so far twoerner. 17:14:42 #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 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 #counter-proposal: Give twoerner until next meeting to have all of the above concerns addressed 17:15:26 mjg59: the network zones support in NM will cope, it's just a matter of not publicizing the feature, fwiw 17:15:31 is the virt issue fixable? 17:15:43 sgallagh: And if not, then what? 17:15:46 notting: patches exist, libvirt is somewhat unhappy about pushing them to f17 this late 17:15:47 Then revert 17:16:01 sgallagh, zones also? 17:16:06 sgallagh: that would be s/twoerner/jpopelka/ 17:16:16 mitr: Sure, sorry. 17:16:17 limburgher: see my comment to mjg59 above 17:16:19 notting: the virt issue is fixed now.. patch will be upstream in some seconds 17:16:36 Ok, so how about 17:16:43 sgallagh: next meeting is bad for me.. will be on vacation starting tomorrow 17:16:44 mitr: got it. 17:16:46 #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 twoerner: That doesn't inspire terrible confidence in me as to getting this finished :( 17:17:04 * mitr is mildly +1 17:17:24 mjg59: I think I'm going to have to agree with that. +1 17:17:26 Yeah, I lean +1 - while I really want this feature, I don't think it's quite ready 17:17:32 mjg59: +1 17:17:33 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 twoerner: what are your thoughts? I know you have worked hard on this... 17:17:40 +1 17:17:48 I do like the command-line interface, but the breakage is difficult to overlook 17:17:58 Yeah, I agree. It's a fantastic feature, but I don't feel it's quite ready. 17:17:59 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 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 nirik: I think it is in a usable state 17:19:09 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 nirik: zones could solve a lot of problems of users with different connections 17:19:34 twoerner: But zones are currently not exposed in the NM UI? 17:19:36 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 mjg59: no 17:19:58 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 mjg59: but to the fireall-applet 17:20:07 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 notting: I'd argue we should just drop it in rawhide now? 17:20:50 notting: there needs to be some time for users to migrate 17:21:40 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 expert iptabels users are using static firewalls 17:22:15 for now 17:22:18 mitr: it isn't? expert users can't turn off firewalld and use their old tables? 17:22:34 pjones: Sure... but then the meaning of "flag day" is vague 17:23:34 so, sounds like we would like to revert for f17? 17:23:37 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 whats involved in doing that? and who has that as action items? 17:23:53 mitr: i'm fine with keeping a flag day. 17:24:03 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 yeah, deferring would mean pushing the flag-day along 17:24:10 i'm a mild +1 to revert 17:24:22 the question here is what needs to get reverted in that case? 17:24:34 nirik: revert is swapping some packages in comps, and ... i believe swapping the state of the iptables service files? 17:24:35 every change for zones and firewalld? 17:24:35 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 twoerner: honestly - probably comps? 17:24:57 what notting said 17:24:58 Anything in anaconda or preupgrade? 17:25:07 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 AFAICS comps, systemd unit files for firewalld/iptables (?), and I'm not sure about control-center printer support 17:25:10 notting: right 17:25:18 limburgher: no 17:25:26 Right, it's best if the packages stay in. 17:25:49 Also, there's the dhcpv6 config for iptables 17:25:51 control-center printer support never was working without firewalld 17:25:59 as far as I know 17:26:01 mitr: twoerner said that was fixed in the latest 17:26:03 limburgher: anaconda just uses comps 17:26:06 Well that's unfortunate 17:26:53 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 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 so, http://fpaste.org/wC6N/ for iptables, and reverting edb2eb2ef86a63cd86043c77bc808db65cf0b40f in comps 17:27:59 mjg59: 1) relax default firewall to let printers in, 2) push through the libvirt changes 17:28:06 mjg59: if there would be some startup code to enable the needed firewall setting 17:28:12 mitr: ew ew ew 17:28:28 mjg59: Also, zones are... there but not very visible 17:28:39 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 And it's probably the kind of change that would result in screaming 17:29:06 Not that I'm adverse to changes that result in screaming 17:29:07 mjg59: what changes are you thinking of? 17:29:25 twoerner: If we're letting in mdns then we should also talk about upnp 17:29:43 And does Salut/Bonjour need anything other than open mdns? 17:29:47 mjg59: right, both 1) and 2) are a little late in beta 17:29:57 Yeah 17:30:17 Well, in that case I guess we probably go with reverting for F17 and concentrate on F18 17:30:25 mitr: both 1) and 2) are simple fixes.. use "home" as the default zone 17:30:37 twoerner: It's the policy change, not the technical side of it 17:30:43 twoerner: home allows everything? 17:30:54 notting: a lot of things for desktop use 17:31:06 notting: ssh ipp-client mdns samba-client dhcpv6-client 17:31:24 how does that fix libvirt? 17:31:37 notting: ssh, ipp-client, mdns, samba-client and dhcpv6-client 17:32:29 notting: libvirt needs 2 new patches.. one to get dbus working in libvirt and the other to add firewalld suppport 17:33:13 notting: the dbus patch is already upstream (from Daniel P. Berrange) 17:33:24 * gholms rings the 30 minute bell 17:33:43 notting: the other one will be as soon as I have time to send it with TAB to space migration 17:34:10 still, a little late for that. 17:34:22 mjg59: what's the tally at the moment? anyone want to change? 17:34:33 +8 to revert, +9 if pjones was 17:35:04 I think I'm sticking with +0; it seems awfully much like we're punishing twoerner for following the feature process. 17:35:06 I'm wavering at +0 right now 17:35:39 Anyone want to change? 17:35:42 pjones: given the 6 months pause in commits at the time of original feature proposal, I'm not sure about that 17:35:52 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 (not that I don't have projects with a larger pause in commits :) ) 17:36:05 mitr, and that's and argument too 17:36:07 I think twoerner has done great work, but I think this will be much nicer in f18. ;) 17:36:11 Ok 17:36:15 i'm not sure it's right to look at delaying a feature as 'punishing the feature's developer', tbh. 17:36:32 it seems an unnecessarily negative/personalized way of considering things. 17:36:39 yeah 17:36:45 #agreed Feature should be deferred to F18, appropriate changes made to F17 (+7, -0) 17:36:54 adamw: you can look at it however you like. 17:37:08 twoerner: so, just the comps change and the iptables packagechange? 17:37:12 twoerner: Sorry it didn't work out for F17 - I'm really looking forward to this 17:37:17 notting: yes 17:37:21 twoerner: i can do comps, you want to do the iptables package? 17:37:41 notting: ok 17:37:50 #topic #839 Proposal for revitalizing the packager sponsorship model 17:37:55 .fesco 839 17:37:56 mjg59: #839 (Proposal for revitalizing the packager sponsorship model) – FESCo - https://fedorahosted.org/fesco/ticket/839 17:38:56 tibbs: Around? 17:39:03 Yeah. 17:39:04 I'm in favor of the "diverge sponsers from PP" and make anyone who wants to be one a sponsor proposal. 17:39:05 the draft proposal looks very good to me 17:39:12 Yes, this seems broadly sensible 17:39:16 I was just looking for comments; obviously there are plenty of tunables. 17:39:22 I think bringing this up on devel@ would be great 17:39:24 * nirik likes the proposal in general. 17:39:46 is the sponsor -> implicit in FAS? 17:39:47 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 It is not. 17:39:57 1. the current sponsors would have to be made PPs automatically if these roless will be disconnected 17:40:10 All current sponsors are provenpackagers. 17:40:12 tibbs: so if i've been forgetting to add sponsors to PP, it's been accidentally severed 17:40:38 Ah, correct. Yes, I've assumed that whoever has been pushing those buttons have been doing both things. 17:40:44 I like it. 17:40:47 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 mitr: This isn't about provenpackager, except that we'd no longer have sponsor imply it. 17:41:33 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 I'm trying not to get into what the criteria for being made provenpackager would be. 17:41:40 tibbs: I think mitr is asking whether part of the goal here is to have targeted sponsors 17:41:43 tibbs: I was thinking about the "area-specific sponsor" aspect. 17:41:47 i.e. Sponsors who specialize in PERL packages 17:42:03 I made no consideration of that idea. 17:42:14 I don't honestly see the point, honestly. 17:42:14 we already have some sponsors who are specialized in one area and they are sponsoring people in the area 17:42:17 Because with the current assumption of provenpackager, it implies a wider general knowledge 17:42:25 (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 mitr: To some extent, I think we already have that. 17:42:46 Again, trying to avoid staying out of provenpackager here. 17:42:53 mmaslano: Which is great. 17:42:59 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 And trying not to add things like domain-specificity to sponsors, when we have no infrastructure that could enforce that. 17:43:12 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 tibbs: Nor should we, really, IMHO. 17:43:27 notting: As it is now. 17:43:28 tibbs: The thing is, the criteria as stated lead to accepting area-specific sponsors. 17:43:35 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 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 It is difficult to quantify pretty much anything about reviews. 17:43:55 Sure 17:43:56 t8m: given the sponsor -> sponsoree mapping isn't necessarily tracked anywhere... don't think so 17:43:58 t8m: thats one thing this proposal is talking about doing. 17:44:06 It would be possible. I looked briefly into it but it's a bit involved. 17:44:13 notting, I thought it is tracked in FAS 17:44:25 That is the one remaining technical issue that needs working out before this could proceed (if approved). 17:44:29 it's tracked in the fas db, but not exposed very well 17:44:30 it is in FAS. 17:44:41 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 The problem is that ACLs aren't generated from FAS, they're generated from pkgdb. 17:45:13 I'm not sure what an area-specific sponsor would be, and honestly wouldn't want to define things that narrowly. 17:45:30 Any more feedback on this for now, or should we let it get discussed on devel? 17:45:32 Once you get sponsorship status, you have it. Whether you choose to restrict yourself would be your decision. 17:45:32 proposal: have discussion on devel list, adjust per feedback and vote on next week or whenever it's ready? 17:45:44 +1 17:45:44 tibbs: I agree, I think you misunderstood. 17:45:52 nirik: +1 17:45:56 Not sure we even need to vote on this 17:45:59 tibbs: It would be relaxing the rules to become a sponsor such that area-specific is possible 17:46:14 Anyone think this is a bad idea? 17:46:16 #proposal: Accept tibbs proposal as-is 17:46:21 nirik, +1 17:46:21 +1 17:46:29 sgallagh: I think that would occur organically. 17:46:35 mjg59: The meetings and minimum requirements are a gamble, but worth the risk I think. 17:46:45 limburgher: Yes. I'm not trying to force it. 17:46:47 My proposal is pretty relaxed as is, I think, with an eye towards making it easy and mostly self-governing. 17:46:50 I'd like to see some more details worked out... and the tunables adjusted before we approve it. 17:46:53 sgallagh: -1 17:47:02 sgallagh: as smart as we are, having some broad discussion would be good 17:47:03 But my office has been invaded by electricians now, so I have to run. Thanks for the discussion. 17:47:04 how does this handle things like fesco-sponsored comaintainers? 17:47:08 #agreed Raise proposal on devel@, bring it back to fesco once there's been wider discussion 17:47:14 pjones: Fair enough 17:47:32 #topic #830 define requirements for secondary arch promotion 17:47:35 .fesco 830 17:47:36 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 :) 17:48:16 Anyone else just hear a "foop" sound? 17:48:44 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 whats the link to the proposal again? 17:49:02 Oof! 17:49:08 http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements_%28Draft%29 17:49:13 thanks 17:49:26 * jonmasters also asked for clarification of things like "sufficient developer resources" that is still missing 17:49:46 (does that mean hardware, people, etc. - I had a few things in my email, not just this one) 17:49:51 jonmasters asked whether we wanted to impose any requirements about integration of ports into documentation 17:50:04 ...or the website, etc. 17:50:12 jonmasters: I thought we covered that in the thread? I don't think it can really be clarified 17:50:28 The idea is that if you're slowing down development of the port then the developer resources aren't sufficient 17:50:31 mjg59: well, even unofficially. Were you meaning to imply people or machines as "resources"? 17:50:36 Yes 17:50:42 :) 17:50:48 *or* :) 17:50:56 examples and clarification, are evidently not appropriate to this document. 17:51:02 jonmasters: yeah, you should totally add a documentation requirement on the wiki 17:51:37 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 that's in the logs plenty of times. 17:51:59 good, just making sure it's logged again 17:52:01 The examples and clarifications that have been asked for were things that *I* didn't think were appropriate 17:52:11 though I don't think anybody has said they're /irrelevant/. 17:52:11 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 That doesn't mean that examples and clarifications are inherently inappropriate, or even that the ones asked for were inappropriate 17:52:22 mjg59:I've taken the silence of other fesco members on this point to mean agreement with you 17:52:26 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 nirik: problem is the whole Fedora Project website is very x86 assuming at the moment 17:52:51 how can we clarify "sufficent developer resources"? "You must have 26 developers, no more, no less"? 17:53:04 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 jonmasters: yeah, but how much change is there really? install is different... but software should all be the same right? 17:53:20 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 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 mitr: which is one of the reasons we don't want to quantify that 17:53:51 please do propose alternate docs wording. ;) That was just off the top of my head. 17:54:04 pjones: This was reacting to "have sufficient resources to keep [the docs] uptodate" 17:54:09 I didn't say anything about the arm team doing all that work. 17:54:20 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 mitr: I assume he means the docs team has to have sufficient resources. 17:54:34 oh, right. sorry 17:54:35 resources there might include people available to answer questions from the docs and websites teams. 17:54:50 right 17:54:53 "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 right, same thing we have for various things within the PA as it currently stands. 17:55:34 jonmasters: Nobody's ever going to put a hard number on this 17:55:42 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 personally, i'd expect to have someone named as the ARM kernel maintainer 17:56:09 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 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 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 whether it's a paid position, or someone in the community is irrelevant 17:56:27 bconoboy: good lord, no 17:56:38 bconoboy: not "do things and *then* talk to us". That's completely wrong. 17:56:42 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 and yes, continued communication is vital. 17:57:13 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 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 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 mjg59: +1 17:57:45 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 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 mjg59: I look forward to the future OpenRISC PA push with much interest :) 17:59:19 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 jonmasters: Ok, so I suspect that you're going to have no problems meeting that requirement 17:59:46 mjg59: Today? No. More of the community does need to be engaged. We're talking process 17:59:52 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 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 Anyone think we need anything stronger for documentation/website requirements? 18:00:58 nirik: that's nice 18:01:11 nope, I'm fine with the draft as is 18:01:11 (I'm fine with nirik's suggestion) 18:01:12 As much as I dislike using the word "dialog" as a noun, that's fine. 18:01:18 Nothing concrete. If FESCO's evaluating the candidate, we'll evaluate. 18:01:42 Ok, so subject to adding some language about docs/website, do we want any other changes made? 18:01:44 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 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 ok, so it's a fluid, ongoing process? 18:03:13 fesco isn't worried about the process because fesco is the process :-P 18:03:23 nirik: Yes, and that will help put legs on getting the whole thing going. 18:03:39 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 nirik, +1 18:03:43 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 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 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 would weekly status updates help us? or be a burden on us/arm team? 18:04:59 mjg59: maybe that's a criteria then ;) 18:05:07 jonmasters: This document provides you with a bunch of indications as to whether anyone is likely to object 18:05:13 nirik: how about we do at least monthly status reports for you? 18:05:15 jonmasters: Well, it does say that already 18:05:17 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 we'd like to get in the habit of doing that anyway 18:05:42 (to foster broader engagement) 18:06:02 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 ok 18:06:28 yeah, status reports would be nice, that way we know whats going on and if there are red flags for anyone. 18:06:31 which, I mean, you could totally start on even without this being approved to be honest. 18:06:46 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 pjones: Do you want this proposal as a feature page? 18:06:56 Weekly is unnecessarily frequent, I think... 18:07:03 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 bconoboy: Isn't there already one? :) 18:07:19 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 yeah, I don't want to burden us or arm with too useless status reports. 18:07:26 bconoboy: I don't think the stuff in the middle needs to be that 18:07:28 mitr: Sure is- I imagine we'll simply update it to reflect the 10-point list. 18:07:38 bconoboy: there's no need for that level of formality. 18:07:59 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 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 We do also need to improve the accessibility for new developers - we're working on all of this 18:08:35 Because that way you're going to get earlier feedback, even from people who aren't actively involved in your port 18:08:42 right 18:08:49 And the more feedback you get, the less likely it is that someone will object 18:08:50 yeah, doing irc meetings in fedora-meeting would be a good step too, IMHO. 18:09:13 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 we'll do a test run of using fedora-meeting and see how it goes 18:09:35 It's not a requirement, it just means it's much more likely that you'll make everyone happy 18:09:42 If it turns into "Kevin's forum for hating on ARM" I'll be wanting to rethink that 18:09:56 If people are disrupting meetings then that's something for the cwg 18:09:56 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 mjg59: well, that was my main resistance. But, yea, we'll try fedora-meeting this week 18:10:42 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 If it happens then let us know. We'll make sure it doesn't again. 18:11:04 if folks disrupt meetings, please let us know. 18:11:20 ok, then, we'll switch to fedora-meeting from this week 18:11:23 Great 18:11:40 Also, blog more 18:11:58 People will pay more attention to a project if they hear things about it 18:12:00 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 yea, I've been meaning to. Sadly I spent a lot of last week tracking down bugs like the audit problem 18:12:49 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 Ok. Do we want to vote on these and take the draft marker off? 18:13:01 Another advantage to IRC meeting is that interested parties can lurk more easily. :) 18:13:34 proposal: we accept these criteria now, with the expectation that the SA will come up with plans to meet them. 18:13:41 +1 18:13:45 +1 18:13:53 +1 18:13:55 * pjones +1 18:13:56 +1 18:13:59 +1 18:14:05 +1 18:14:09 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 jonmasters: Exactly. Open by default. :) 18:14:38 mmaslano? t8m? 18:14:40 I'm not opposed :) 18:14:48 +1 18:14:48 +1 18:14:51 Ok 18:15:16 the motion passes with unanimity. 18:15:20 #agreed Secondary architecture promotion requirements are approved, we'll continue followup discussions with secondary architectures over plans to implement them 18:15:26 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 jonmasters: Sounds good to me. We'll see how that goes. 18:15:43 * bconoboy signs jonmasters up for that 18:15:43 jonmasters: you're free to do status reports as often as you like. 18:15:57 preferrably where "like" is not "never" 18:15:58 :) 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 jonmasters: bconoboy: Thanks for your patience on this. Your input has been valuable. 18:16:34 hey, thanks guys 18:17:02 #topic Next week's chair 18:17:03 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 best of luck to arm. Looking forward to it. ;) 18:17:49 fyi I won't attend next and also the next week 18:17:50 I will be out next week, so I cannot chair. 18:18:01 Anyone else going to be missing next week? 18:18:03 nirik: you think that's fun, wait until we have some 64-bit ARM goodies to share ;) 18:18:19 Not that I know of. 18:18:29 Should still have enough for quorum, then 18:18:35 Anyone willing to volunteer? 18:18:39 i will have to leave ~ 2:15, so i'm not the best choice. will be here, though 18:18:50 People hate when I chair. . . 18:18:57 limburgher: Perfect. You can chair. 18:19:02 D'oh! 18:19:04 Ok. 18:19:11 #agreed limburgher chairs next week 18:19:15 #topic Open Floor 18:19:16 Heh 18:19:19 Anyone got anything? 18:19:20 mjg59, I might not be able to attend next week as well 18:19:41 t8m: Ok - should still be just about ok, but if anyone else vanishes we may not make quorum 18:19:47 We'll see how it goes 18:20:03 Do we want #840 today or next week? 18:20:03 Probably best to assume we'll have a meeting just in case any post-beta disasters arise 18:20:29 mitr: It was opened 98 minutes ago, I think we leave it 18:21:24 Ok, I'll close out in a minute if nobody has anything more 18:22:00 #endmeeting