=================================== #fedora-meeting: FESCO (2014-02-19) =================================== Meeting started by t8m at 18:00:18 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-02-19/fesco.2014-02-19-18.00.log.html . Meeting summary --------------- * init process (t8m, 18:00:40) * #1136 F20 System Wide Change: ARM as primary Architecture - https://fedoraproject.org/wiki/Changes/ARM_as_Primary (t8m, 18:04:15) * #1178 Fedora 21 scheduling strategy (t8m, 18:05:25) * AGREED: Defer the ticket for a week to gather info from WGs (+6, -0, 0:0) (t8m, 18:10:05) * #1179 Interactions of the various Products (t8m, 18:11:04) * AGREED: FESCo wants Fedora to continue to have a core set of features that all Products must implement. We'll defer decisions about who decides on these core features and what those features cover until after we get more input from Products about how they are expecting to diverge. (+7, -0, 0:0) (t8m, 18:55:12) * #1197 Procedure for suggesting/approving different Products and/or WGs? (t8m, 18:55:28) * AGREED: Close for now until the current products are released at least once and/or anyone proposes a new product (+7, -0, 0:0) (t8m, 19:06:43) * Many FESCo members think that the bar for the new products should be relatively high (t8m, 19:06:57) * Spins continue to exist (t8m, 19:07:44) * #1198 Possible changes to Fedora EOL bug procedure (t8m, 19:08:10) * AGREED: the new mattdm's proposal for EOL bug procedure is approved (+6, -0, 0:0) (t8m, 19:11:45) * ACTION: mattdm to coordinate with bugzilla maintainers to get the practical parts implemented (mattdm, 19:11:58) * AGREED: The pre-EOL warning still stays (with appropriate change of wording) (+7, -0, 0:0) (t8m, 19:14:08) * #1233 Nonresponsive maintainer: steve (mattdm, 19:21:09) * AGREED: steve will be changed to comaintainer and the packages orphaned with the perl-* packages assigned to psabata (+7 -0 0:0) (t8m, 19:21:42) * #1234 Close a loophole in the Nonresponsive Maintainer procedure (t8m, 19:22:34) * AGREED: cvsadmins should be advised not to reassign packages without FESCo approval (+8, -0, 0:0) (t8m, 19:25:39) * ACTION: dgilmore will mail cvsadmins not to reassign packages without FESCo approval (t8m, 19:26:20) * #1236: Change process for F21/Fedora.Next (t8m, 19:30:49) * AGREED: Open up F21 for ordinary Change proposals _now_, and continue the conversation about adapting the process for .next in the mean time. (+6, -0, 0:0) (t8m, 19:42:46) * Next week's chair (t8m, 19:43:46) * ACTION: nirik will be the chair next week (t8m, 19:45:38) * Open floor (t8m, 19:45:44) * AGREED: FESCo expects the Tech specs/docs from working groups by March 3rd at the latest (+7, -0, 0:0) (t8m, 19:50:38) * ACTION: t8m will update the weekly reports ticket with this request (t8m, 19:53:08) Meeting ended at 19:55:10 UTC. Action Items ------------ * mattdm to coordinate with bugzilla maintainers to get the practical parts implemented * dgilmore will mail cvsadmins not to reassign packages without FESCo approval * nirik will be the chair next week * t8m will update the weekly reports ticket with this request Action Items, by person ----------------------- * dgilmore * dgilmore will mail cvsadmins not to reassign packages without FESCo approval * mattdm * mattdm to coordinate with bugzilla maintainers to get the practical parts implemented * nirik * nirik will be the chair next week * t8m * t8m will update the weekly reports ticket with this request * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * t8m (133) * nirik (98) * mattdm (71) * abadger1999 (59) * mitr (57) * dgilmore (41) * pjones (30) * zodbot (18) * notting (5) * drago01 (2) * pingou (2) * bconoboy (1) * sgallagh (0) * mmaslano (0) * jwb (0) -- 18:00:18 <t8m> #startmeeting FESCO (2014-02-19) 18:00:18 <zodbot> Meeting started Wed Feb 19 18:00:18 2014 UTC. The chair is t8m. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:25 <t8m> #meetingname fesco 18:00:25 <zodbot> The meeting name has been set to 'fesco' 18:00:32 <t8m> #chair abadger1999 dgilmore mattdm mitr notting nirik pjones t8m sgallagh mmaslano jwb 18:00:32 <zodbot> Current chairs: abadger1999 dgilmore jwb mattdm mitr mmaslano nirik notting pjones sgallagh t8m 18:00:40 <t8m> #topic init process 18:00:40 <pjones> hello. 18:00:41 <mitr> Hello all 18:00:44 <t8m> Hi all 18:00:49 <nirik> morning 18:00:55 <abadger1999> Greetings 18:01:04 <mattdm> good afternoon! 18:01:15 <t8m> good evening :) 18:01:21 <bconoboy> good morning 18:02:24 <mattdm> :) 18:02:43 <t8m> dgilmore, around? 18:03:34 <t8m> as we have too many tickets to process and the quorum is already in we should start 18:03:56 * dgilmore is here 18:04:15 <t8m> #topic #1136 F20 System Wide Change: ARM as primary Architecture - https://fedoraproject.org/wiki/Changes/ARM_as_Primary 18:04:22 <t8m> .fesco 1136 18:04:24 <zodbot> t8m: #1136 (F20 System Wide Change: ARM as primary Architecture - https://fedoraproject.org/wiki/Changes/ARM_as_Primary) – FESCo - https://fedorahosted.org/fesco/ticket/1136 18:04:29 * dgilmore honestly thought this was all done 18:04:33 <mattdm> I mostly wanted to make sure that we hadn't missed anything here. 18:04:46 <t8m> mattdm, I suppose we hadn't 18:04:48 <mattdm> From the first time we had a discussion I expected a final review and rubber-stamping 18:04:48 <nirik> I don't think we did. 18:05:08 <mattdm> if we feel like that's not necessary (and I guess that's the consensus), then, yeah, movin on :) 18:05:14 <t8m> ok moving on 18:05:23 <t8m> I'll close the ticket 18:05:25 <t8m> #topic #1178 Fedora 21 scheduling strategy 18:05:30 <t8m> .fesco 1178 18:05:31 <zodbot> t8m: #1178 (Fedora 21 scheduling strategy) – FESCo - https://fedorahosted.org/fesco/ticket/1178 18:05:55 <nirik> I don't know what we can really do here yet... we still don't have sufficent info IMHO. 18:05:57 <mattdm> sgallagh had a draft message 18:06:11 <mattdm> i think right now, we are waiting for that draft to go out 18:06:11 <dgilmore> we can set a release date 18:06:19 <dgilmore> and do what can be done in that time 18:06:44 <mitr> No 18:06:46 <nirik> dgilmore: I'd hate to do that and have some product be unable to do much because lack of time tho 18:06:46 <mattdm> in the individual working groups (at least in cloud) we are slowly forming an unordered list into a useful one 18:06:58 <dgilmore> nirik: sure, not saying its ideal 18:07:03 <dgilmore> its just an option 18:07:05 <t8m> dgilmore, it's too premature as we do not really have input from WGs on timing of their needed change 18:07:08 <t8m> changes 18:07:30 <nirik> so, proposal: defer this and hope to gather useful info from working groups soon on scope of changes. 18:07:36 <t8m> nirik, +1 18:07:39 <mattdm> I think sgallagh is on vacation until tomorrow? 18:07:41 <dgilmore> nirik: +1 18:07:47 <nirik> mattdm: yeah, he's out today at least 18:07:50 <mattdm> nirik +1 18:07:51 <t8m> nirik, defer for a week? 18:08:03 <mitr> t8m: if we haven't even sent that email, probably more 18:08:12 <t8m> mitr, I'd say so 18:08:13 <nirik> sure, I think we should revisit it often, perhaps we will have some glimmers next week 18:08:15 <pjones> nirik: +1 18:08:21 <abadger1999> if sgallagh sends the email tomorrow we could get back to it next week. 18:08:22 <mattdm> mitr: well, everyone *should* be _expecting that mail 18:08:30 <mattdm> +1 next week and we'll see where we area 18:08:33 <mattdm> are 18:08:34 <t8m> ok 18:08:51 <dgilmore> we will need a week after the WG's get their changes in for qa and releng at least to see whats doable 18:08:53 <nirik> I'll note that we are past the orig deadline we set for list of deliverables/changes in process. ;) 18:09:02 <mattdm> maybe we could also add a "hey, what do you think the ideal release date would be?" 18:09:04 <dgilmore> probbly will need infra, marketing and websites also 18:09:07 <abadger1999> mattdm: +1; we'll keep discussing it until we've resolved it anyhow :-) 18:09:10 <nirik> dgilmore: yeah, and all the other groups too. 18:09:29 <mattdm> i know workstation for example would probably like to coordinate with the gnome 3.14 release 18:09:45 <abadger1999> mattdm: not sure about asking for an ideal release date, thouhg... there's a lot of manpower needs outside of the working groups to make things happen. 18:09:59 <abadger1999> So schedule is likely more being set by teams outside of the working groups. 18:10:05 <t8m> #agreed Defer the ticket for a week to gather info from WGs (+6, -0, 0:0) 18:10:18 <mattdm> abadger1999 that makes sense too 18:10:22 <t8m> with implicit nirik's +1 18:10:31 * nirik nods 18:10:53 <t8m> let's move on 18:11:04 <t8m> #topic #1179 Interactions of the various Products 18:11:09 <t8m> .fesco 1179 18:11:10 <zodbot> t8m: #1179 (Interactions of the various Products) – FESCo - https://fedorahosted.org/fesco/ticket/1179 18:12:18 * mattdm rereads ticket 18:12:43 <mattdm> So toshio asked a question: "One thing to talk about is whether we want to have somethings that are necessary for all Fedora Products (SELinux on; systemd as the init system; running syslog, cron, and smtp daemons; linux kernel; etc). And if so, whether we want the Base Design WG to do that." 18:12:45 <t8m> So, do we have any concrete proposal to vote on this? I suppose not yet. Any volunteers to create for example a wiki page where they could be gathered? 18:12:52 <mattdm> I think the answer is "yes, that is what the base design is for" 18:13:17 <mitr> I think there was a strong consensus to minimize deviations in configuration, which is sort of a "default answer". 18:13:26 * pingou thought base was the mandatory bits that every product is based upon 18:13:53 <mitr> And yes, base would be the right place to shepherd new functionality and resolve conflicts in that area. 18:13:59 <t8m> pingou, sure, but the base bits probably could be configured differently if really needed for different products 18:14:34 <t8m> for example we might want rsyslog on in server, perhaps not so much in workstation or cloud 18:14:37 <pingou> t8m: true but if base end up not being used by all products, then I don't understand why it exists at all 18:14:47 <pjones> mattdm: yeah, I think you're right. 18:14:51 <t8m> pingou, it will be used by all products 18:14:54 <abadger1999> mattdm: Cool. We should approve something about that and pass the mandate on to the base WG then... jwb felt that we hadn't mentioned that as something we wanted Base to do. 18:15:15 <nirik> I think we are just going to have to feel out way along here... 18:15:22 <mattdm> +1 nirik 18:15:35 <nirik> some things will need to be decided by base folks, but others could be different in the products... 18:15:46 <mattdm> I have the expectation that if the base "mandates" soemthing, and that doesn't meet the needs of the product, we'll work something out. 18:15:49 <nirik> workstation is also talking (on list) about not having a firewall... 18:16:14 <mattdm> cloud is *already* not wanting a firewall. 18:16:16 <dgilmore> cloud has turned iptables off, which I dont like 18:16:18 <nirik> but some things definitely would be base... kernel, systemd, etc. 18:17:14 <abadger1999> mattdm: Would it be okay for that to be something that cloud and workstation present to base and base figures out if it's okay, and if so, to what extent? 18:17:22 <dgilmore> im pretty sure iptables is in base 18:17:33 <nirik> firewalld is likely too 18:17:35 <dgilmore> but configuration can be done outside of it 18:17:38 <nirik> anaconda requires it 18:17:42 <dgilmore> yeah 18:18:09 <mattdm> nirik anaconda as of f18/f19 required firewalld. but it doesn't in f20 18:18:28 <mattdm> if the firewall is disabled and you don't include that package, it will let you. 18:18:29 <abadger1999> dgilmore: sure... but htere's "Base -- the minimal set of packages and services that other Fedora Products are based on" and "Base Design -- the minimal guarantees we make about what a Fedora system has" 18:18:29 <pjones> I think we may be getting a bit too caught up on the present here. 18:18:34 <nirik> oh really? 18:18:39 <nirik> yeah. 18:18:43 <nirik> pjones: +1 18:18:45 <mattdm> pjones yes 18:18:51 <t8m> pjones, +1 18:18:54 <abadger1999> pjones: +1 18:19:10 <mattdm> i can go on about firewalld all day and probably shouldn't :) 18:19:18 <dgilmore> firewalld is in anaconda-tools group in comps 18:19:36 <dgilmore> abadger1999: sure 18:20:02 <t8m> Any concrete proposal to vote on? 18:20:09 <nirik> so where do we go from here? just see docs from working groups and ask them to shunt some to base that make sense? 18:20:50 <t8m> nirik, who will do that review, FESCo members? 18:20:53 <abadger1999> For my Base question specifically, I think we need to tell Base that this is something that we want them to be in charge of. 18:21:28 <mattdm> abadger1999 okay :) 18:21:30 <nirik> t8m: dunno. I guess. 18:21:37 <abadger1999> since the question came up already. 18:21:40 <mitr> I have started that ticket with a goal that "application development for Cloud and Server happens on Workstation", and trying to define what was necessary for _that_. There wasn't consensus that we need to be explicitly designing this interaction IIRC. 18:21:44 <nirik> abadger1999: so do we want some specific list? 18:22:48 <mitr> I think it makes more sense now to just deal with common items as they come up (using the liaison reports), and not try to draft any kind of intended-to-be-completed list now. 18:23:24 <abadger1999> nirik: Are you thinking with entries like: "Base Design is in charge of determining * what services are allowed to be enabled by default when they are installed" "* what services must be installed and running on any Fedora system" 18:23:28 <t8m> mitr, +1 18:24:00 <nirik> abadger1999: I guess... 18:24:30 <abadger1999> If that's what we'd like to vote on, I can write something up this week. 18:25:26 <mattdm> I'm good with that with the understanding that the idea is to keep Fedora generally cohesive while serving the needs of the products. If this becomes an area of _conflict_ between base & products, soemthing is going wrong. 18:25:56 <pjones> mitr: +1 18:26:28 <pjones> mitr: since it seems there's literally 0% chance we'd get it right at this stage, it seems like that shouldn't be something we try to make concrete rules for yet. 18:26:36 <nirik> abadger1999: not sure we are at that point yet tho... like for example with 'enabled by default' we could well have different systemd presets per product. 18:27:28 <abadger1999> nirik: <nod> So -- my thinking is that Base might specify that as well. 18:27:29 <mitr> pjones: Well, the Workstation WG did https://fedoraproject.org/wiki/Workstation/Technical_Specification ; having something like that from the other products might actually make sense (... but we don't have that now). 18:27:41 <mattdm> mitr yeah, that's nice 18:27:54 <pjones> mitr: opposite direction though - that's the projects doing it, not us 18:28:42 <abadger1999> they might decide that Products can choose to enable/disable whatever services they want by default. They might decide that that's the general case but X, Y, Z specific services must be enabled/disabled 18:28:51 <pjones> which is to say it's something that provides useful form for them to go about their work, rather than something to limit them from outside. 18:28:59 <nirik> I guess I would feel better if we had specs from all the products before deciding what we should ask base to manage from that 18:29:05 <abadger1999> Or they might decide that Base needs to approve everything. 18:30:44 <mitr> I guess, Proposal: Close ticket. Rely on liaisons to highlight technical decisions that extend from their WGs, and for now expect to deal with interactions one issue at a time. 18:30:47 <mitr> (We can revisit if all products prepare technical specifications.) 18:31:13 <abadger1999> nirik: okay... Would it hurt to tell Base that htis is something we want them to do in the future but we want them to start thinking about it after Products have some desires to present to them? 18:31:30 <t8m> mitr, +1 18:31:32 <nirik> abadger1999: I surely wouldn't think so... ;) 18:31:42 <pjones> mitr: +1 18:32:24 <mattdm> mitr +1, along with abadger1999's note to base 18:32:26 <nirik> mitr: s/if/when/ ? we should get specs from all products... :) 18:32:31 <mitr> (an reasonable alternative position: ask WGs to prepare technical specifications by $date, use that to figure out the interactions) 18:32:52 <nirik> we have already done that, but need to push the date out. 18:32:56 <abadger1999> nirik: My thought is that right now it seems that Products seem to think that they can diverge on these points but we probably do want to have some core things that are "a Fedora system implements X". So we want to warn everyone that this is something that we see Base as deciding upon. 18:33:35 <dgilmore> mitr: +1 18:34:10 <mitr> abadger1999: Structurally, Base WG "owns" the design and implementation of the base. I think FESCo "owns" the authority to decide which parts are the Base and which parts are not; it would be somewhat strange for Base to just claim an area. 18:34:53 <mitr> (considering the already discussed Base mission statement as FESCo approved or something) 18:34:54 <abadger1999> mitr: I might agree with that... I'm not sure I understand it fully though :-) 18:35:14 <t8m> mitr, I'd agree with this, FESCo should have the authority to choose what Base WG owns 18:35:44 <mitr> (honestly "ownership" is a side issue... but cross-product interactions are clearly a FESCo matter.) 18:35:46 <nirik> abadger1999: I think I'm ok with that, but it should really be base stuff... 18:37:00 <abadger1999> mitr: I'm more saying that everyone seems to accept that Base is building something that the other Products can build on top of. But we aren't all on the same page about whether some parts of Base are modifiable by the products and other parts of Base must be implemented as is in the Products. 18:37:10 <t8m> I am counting +4 for Proposal: Close ticket. Rely on liaisons to highlight technical decisions that extend from their WGs, and for now expect to deal with interactions one issue at a time. 18:37:44 <mitr> abadger1999: My "default" view is that Fedora products all use a single set of technologies, and Products primarily choose which to include/omit. (Too simplistic, sure. Configurations will differ, there are different desktop stacks, we don't worry about having umpteen string libraries. But in the higher-level view I think it's roughly correct.) 18:37:46 <nirik> abadger1999: it's really hard to answer that question until we have the tech specs for all the products... I mean, we don't know what kinds of things they want to do fully. 18:38:41 <nirik> I hope base will also be responsive to products... 'you choose foo, but we need bar, is it ok to add bar on? or can you switch to bar? or do we need bar and foo both?' 18:38:57 <mattdm> nirik +1 18:39:43 <t8m> #proposal Postpone until WGs prepare technical specifications of the products 18:40:25 <nirik> +1 18:40:31 <abadger1999> nirik: I don't think that the basic concept is hard to answer. 18:40:53 <nirik> abadger1999: can you put it into a proposal? 18:40:59 <abadger1999> the basic concept is "Do we want Fedora to have a core set of features that everyone must implement" 18:41:02 <mitr> t8m: is that "indefinitely", or "... and we will ask WGs to do so"? 18:41:17 <abadger1999> and from that, "Do we want the Base Working Group to determine those Features" 18:41:27 <t8m> mitr, yeah we should ask them to do so :) 18:41:57 <abadger1999> Deciding what those features are is where I agree with you that we should wait for more input from the WG's about what they want to do. 18:41:58 <nirik> ok, sure. I am +1 to both those. 18:42:10 <t8m> abadger1999, +1 to first, not so sure about the second 18:42:33 <nirik> I would hope it would be a small list of musts... 18:42:34 <abadger1999> +1 to the first. Willing to discuss the second :-) 18:42:56 <t8m> the base group should work on those features but they should be probably chosen/approved by FESCo 18:43:06 <t8m> IMO 18:43:44 <pjones> t8m: oh god, why? We appointed these people to do the job, why can't we let them? 18:44:34 <pjones> If we don't trust them to at least try and make good, informed decisions, why don't we just jettison the base WG and do it ourselves? 18:44:35 <nirik> yeah, I don't see any reason to micromanage... if they make some bad decision we can override them, no? 18:44:50 <nirik> or convince them to revisit 18:44:52 <mitr> pjones: I don't think "approved" is a must, it's just that FESCo is the place where the products actually meet to interact 18:44:54 <pjones> nirik: yeah, and before that we can, you know, talk to them. 18:44:59 <nirik> right 18:45:03 <t8m> pjones, so Base group is being the people who define what it means that some product is Fedora? 18:45:06 <abadger1999> t8m: okay... so in your view, it would be up to fesco to say things like "All Products must have selinux enabled" and it would be up to Base to make sure that SELinux works for all packages that the products are shipping? 18:45:17 <t8m> abadger1999, yes 18:45:59 <mitr> abadger1999: Or it might be "all products will use the same SELinux setting" and leave it up to base to choose one 18:46:18 <abadger1999> I think I'm with pjones that I'd rather see Base do the decision making. And packagers/Feature Owners do the work to make sure they work as expected. 18:46:22 <mitr> Really, I don't think we don't need to prepare a hypothetical plan for these things. 18:46:31 <t8m> mitr, +1 18:46:58 <dgilmore> lets wait till we get real issues come up to solve 18:47:05 <nirik> I think it might be nice for base to have a set of musts... we just mostly assume them now, but if we have a place for them they could even be revisited or changed sometimes. 18:47:10 <mitr> At this point we really have nothing to work with, and we're certainly not going to complete the list of concerned areas within this meeting. 18:47:40 <t8m> #proposal close the ticket for now 18:47:41 <abadger1999> I'm just responding to something jwb said in the workstation PRD ticket -- that he didn't think the Base WG thought that this was something we wanted from them. 18:47:56 <mitr> t8m: reiterating a +1 18:48:01 <abadger1999> And it sounds like fesco needs to decide on whether we want them to be in charge of this. 18:48:39 <mitr> Our options _this minute_ are a) close and plan to deal with it individually, b) find someone willing to work on a propose a list, and defer until then, c) ask WGs to give us input to create/collate the list, and defer until then. Anything else? 18:49:19 <abadger1999> because as it is now we've just made it more confusing for someone from the WGs who reads the logs to know whether we expect Base to make these decisions or not. 18:49:37 <mattdm> abadger1999 yes _that_ is true. :) 18:49:38 <pjones> abadger1999: hence what mitr is saying :) 18:50:18 <nirik> mitr: d) ask base to come up with a list? 18:50:51 <dgilmore> abadger1999: I think it will be clearer what is bases domain when we get all the Product info in 18:51:32 <mitr> nirik: Actually they sort of already did in https://fedoraproject.org/wiki/Base: 18:51:35 <mitr> The experience from functionalities provided by Base are expected to be consistent across different Fedora products 18:51:37 <mitr> Definition of the Base: Installer, compose tools, minimal install (for some definition there), and functionality the majority products want to use 18:51:47 <dgilmore> it should be assumed that base is responsible for the core pieces, which are not totally clear right now. with FESCo being an escallation point 18:51:54 <nirik> mitr: yeah, but what about things like: 18:52:01 <abadger1999> mitr: <nod> How about this compromise: Proposal: FESCo wants Fedora to continue to have a core set of features that all Products must implement. We'll defer decisions about who decides on these core features and what those features cover until after we get more input from Products about how they are expecting to diverge. 18:52:05 <mitr> nirik: "majority products want to use" is an implicit list, but close enough as a guideline. 18:52:08 <nirik> selinux enforcing, linux kernel, systemd, rpm? 18:52:23 <nirik> abadger1999: sure. +1 18:52:50 <t8m> abadger1999, I can definitely be +1 to this 18:53:12 <abadger1999> nirik: depsolver (dnf/yum/alternative), sshd, 18:53:22 <dgilmore> abadger1999: sure 18:53:26 <mitr> abadger1999: *shrug*, +1 I suppose, that's about equivalent to closing the ticket and waiting for someone to raise an issue :) 18:53:53 <pjones> abadger1999: sure, +1 18:53:58 <nirik> abadger1999: security policy, sudo/wheel, yeah, the list goes on. ;) 18:54:12 <t8m> dgilmore, is that +1? 18:54:15 <mattdm> also sure +1 18:54:26 <dgilmore> t8m: yes 18:54:34 <abadger1999> mitr: the important part for me is that we're telling products that there's certain things that we're going to ocnsider to be "must implement" and "must not implement" for all fedora products. 18:54:36 <t8m> abadger1999, are you +1 on yourself? 18:54:39 <abadger1999> +1 18:55:12 <t8m> #agreed FESCo wants Fedora to continue to have a core set of features that all Products must implement. We'll defer decisions about who decides on these core features and what those features cover until after we get more input from Products about how they are expecting to diverge. (+7, -0, 0:0) 18:55:28 <t8m> #topic #1197 Procedure for suggesting/approving different Products and/or WGs? 18:55:28 <mattdm> (And if some people would like to go outside of that, there's certainly room for a remix.) 18:55:32 <t8m> .fesco 1197 18:55:33 <zodbot> t8m: #1197 (Procedure for suggesting/approving different Products and/or WGs?) – FESCo - https://fedorahosted.org/fesco/ticket/1197 18:56:55 <t8m> So I don't really see a concrete proposal but I might have overlooked it in the lengthy discussion in the ticket 18:57:42 <t8m> I mostly agree with abadger1999's last comment there 18:59:02 <nirik> yeah, I'm not sure where we go from here... perhaps someone could write up a more concrete proposal on how to promote a new thing to a product? 18:59:18 <nirik> it sounds like most of us are on board with spins just staying spins and not being a product really. 18:59:27 <t8m> #proposal Postpone/close until anybody comes up with concrete proposal for a new product 18:59:34 <mattdm> nirik yes, I think the spins part is decided 18:59:35 <abadger1999> Do we agree on the vision? 18:59:42 <mitr> I do see a definite difference between spins and products (without either being "less"). 18:59:48 <abadger1999> (In the future there may be *many* products) 18:59:59 <mitr> t8m: +1. Or alternatively, ... until anyone proposes a product. YAGNI and all that. 19:00:05 <abadger1999> I think that gives people a starting point. 19:00:07 <mattdm> I further think that there's general consensus that there should be a relatively high bar for more products. 19:00:30 <mattdm> the main question is whether that bar should be resourcing-based or, um, story-based 19:00:36 <mitr> (Jóhann mentioned proposing a product, and I'm not actually sure whether he thinks he has already put a proposal to FESCo.) 19:00:37 <t8m> mitr, yeah that's better and more simple wording :) 19:00:47 <pjones> mattdm: I agree, and I also think we need to get this batch working before we start adding more, no matter how high or low the bar is 19:00:54 <nirik> pjones: +1 19:00:56 <abadger1999> mattdm: I think I agree with that pair of statements :-) 19:01:09 <t8m> pjones, +1 19:01:14 * mattdm nods 19:01:17 <abadger1999> pjones: +1 getting the first release w/ products out the door should be our priority 19:01:51 <mitr> abadger1999: I don't expect *many* products. There are only so many general operating systems one would want to use, and specialized niche systems frequently don't need the tight product-like coordination. 19:02:08 * nirik also agrees with mattdm there. 19:02:33 <nirik> It might need to be both things/case by case... based on all the data we can gather would this new thing be good to make a product. 19:02:38 <t8m> #proposal Close for now until the current products are released at least once and anyone proposes a new product 19:02:58 <nirik> t8m: sure, +1 19:03:00 <dgilmore> +1 19:03:01 <mattdm> sure +1 19:03:07 <abadger1999> mitr: I tentatively agree with you... but for me, that means that we provide some non-product-based resources for the niche systems. 19:03:09 <mitr> t8m: +1 (could go with either "and" and "or") 19:03:24 <mitr> abadger1999: Spins continue to exist, yes. 19:03:27 <mattdm> abadger1999 and I think there's agreement that we do and will continue to 19:03:34 <abadger1999> t8m: s/and/or/ ? 19:03:55 <nirik> abadger1999: yeah, we definitely should/are. 19:03:57 <abadger1999> t8m: +1, though 19:03:59 <mattdm> I think we should also note the thing I said about high bar to anyone who floats the idea of proposing a product 19:04:21 <nirik> for example some of the 10,000 rpms we have in our collection are not likely to be in any of our products. ;) yet, we still build and distribute and test them. 19:04:30 <t8m> mattdm, I'd wait for the proposal 19:05:25 <t8m> but I can add a note to the ticket that many FESCo members think that the bar for the new products should be relatively high 19:05:44 <t8m> myself is +1 to my proposal 19:05:46 <dgilmore> nirik: rawhide has armhfp: 70k rpms i386: 72k rpms x86_64: 85k rpms 19:06:04 <pjones> Alright, well, right now we're averaging 3 lines of discussion per minute on this. Do we want to note that in the ticket and move on? 19:06:05 <nirik> cool. :) was thinking srpms, but we are over 10k on that too. 19:06:07 <t8m> #agreed Close for now until the current products are released at least once and/or anyone proposes a new product 19:06:15 * pjones +1 to the proposal 19:06:19 <dgilmore> chances are high a lot of them wont make it to products 19:06:25 <mattdm> t8m my concern is that I don't want something that is unlikely to meet _either_ bar to start something up that doesn't go anywhere, leading to confusiona nd frustration. 19:06:26 <t8m> #undo 19:06:26 <zodbot> Removing item from minutes: AGREED by t8m at 19:06:07 : Close for now until the current products are released at least once and/or anyone proposes a new product 19:06:43 <t8m> #agreed Close for now until the current products are released at least once and/or anyone proposes a new product (+7, -0, 0:0) 19:06:57 <t8m> #info Many FESCo members think that the bar for the new products should be relatively high 19:07:03 <mitr> mattdm: I'd expect mailing list conversations to happen before a large effort is put into a FESCo ticket (but I might be mistaken) 19:07:28 <dgilmore> mitr: I agree 19:07:44 <t8m> #info Spins continue to exist 19:07:51 <dgilmore> I dont think a proposal will come out of the air and blind side us 19:07:51 <t8m> moving on 19:07:56 <mattdm> and maybe this *should* without saying, but I think anyone should expect almost-zero-effort proposals to not go anywhere. 19:08:10 <t8m> #topic #1198 Possible changes to Fedora EOL bug procedure 19:08:15 <t8m> .fesco 1198 19:08:17 <zodbot> t8m: #1198 (Possible changes to Fedora EOL bug procedure) – FESCo - https://fedorahosted.org/fesco/ticket/1198 19:08:47 * nirik voted in ticket here I think. 19:09:28 <t8m> #proposal 1. New "CLOSED:EOL" resolution added. 2. Only the EOL script will be able to put things into CLOSED:EOL 3. Script will be run immediately when a release hits end of life. (Message needs to be adjusted.) 4. Any user will be able to reopen bugs which are CLOSED:EOL, but without special privileges will be made to select a new, open Fedora version 19:09:38 <mattdm> +1 19:09:39 <mitr> +1 19:09:41 <t8m> +1 19:09:52 <nirik> right, +1 19:10:05 <mattdm> notting was +1 in the ticket 19:10:58 <t8m> #agreed the new mattdm's proposal for EOL bug procedure is approved (+5, -0, 0:0) 19:11:12 <nirik> I guess we didn't specifically ping qa folks for input... but they can reopen or open new with further ideas. 19:11:25 <pjones> eh, sure, +1 19:11:36 <mitr> nirik: This seems to be a mechanism change that doesn't affect QA workload 19:11:36 <t8m> #undo 19:11:36 <zodbot> Removing item from minutes: AGREED by t8m at 19:10:58 : the new mattdm's proposal for EOL bug procedure is approved (+5, -0, 0:0) 19:11:45 <t8m> #agreed the new mattdm's proposal for EOL bug procedure is approved (+6, -0, 0:0) 19:11:58 <mattdm> #action mattdm to coordinate with bugzilla maintainers to get the practical parts implemented 19:11:59 <nirik> mitr: there was talk about reviving a triage type group... it may affect them... hard to say 19:12:09 <mitr> nirik: Yes; not part of the proposal 19:12:12 <nirik> right. 19:12:35 <nirik> and also unrelated, but exciting... I am sure looking forward to bugzilla fedmsgs. ;) 19:12:41 <t8m> #proposal The pre-EOL warning still stays 19:12:52 <t8m> +1 19:12:59 <mitr> +1 19:13:07 <dgilmore> +1 19:13:07 <mattdm> t8m +1. wording change as appropriate, of course. 19:13:12 <t8m> sure 19:13:19 <nirik> sure, +1 19:13:31 <abadger1999> +1 19:13:49 <mattdm> notting was also baseically +1 in the ticket 19:13:58 <notting> Yup 19:13:58 <mattdm> ("I don't see why it hurts, if it's simple enough to do.") 19:14:08 <t8m> #agreed The pre-EOL warning still stays (with appropriate change of wording) (+7, -0, 0:0) 19:14:13 <t8m> let's move on 19:14:25 <t8m> #topic #1221 Product working group activity reports 19:14:29 <t8m> .fesco 1221 19:14:30 <zodbot> t8m: #1221 (Product working group activity reports) – FESCo - https://fedorahosted.org/fesco/ticket/1221 19:14:53 <mattdm> no one added anything to the ticket 19:15:08 <mitr> t8m: I think those are supposed to be bi-weekly and we've had reports last week 19:15:19 <t8m> ah ok 19:15:20 <nirik> yeah, I suspect lots of people were getting over the flu/travel doom... 19:15:22 <t8m> moving on 19:15:38 <t8m> #undo 19:15:38 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x2d1ceb10> 19:15:45 <t8m> #topic #1233 Nonresponsive maintainer: steve 19:15:51 <t8m> .fesco 1233 19:15:53 <zodbot> t8m: #1233 (Nonresponsive maintainer: steve) – FESCo - https://fedorahosted.org/fesco/ticket/1233 19:16:19 <dgilmore> I am okay with finding new primary maintainers and having him be a comaintainer 19:16:23 <nirik> I didn't get anything back from steve unfortunately. 19:16:28 <t8m> So I don't see any activity from steve 19:16:40 <nirik> or did I... let me doublecheck 19:16:45 <mattdm> as noted in the ticket, I got a response from him on google+ 19:16:54 <mattdm> he says that he's been very busy with work. He'd like to find new primary maintainers for his packages and still be a comaintainer. 19:16:56 <nirik> oh right, I did. 19:17:08 <mattdm> and nirik had a proposal 19:17:09 <nirik> yeah. ditto 19:17:14 <mattdm> to which I am +1 19:17:18 <pjones> that sounds just fine. 19:17:28 <mattdm> ftr... 19:17:36 <nirik> have the perl ones been reasigned yet? 19:17:39 <t8m> +1 to the proposal 19:17:44 <t8m> nirik, not yet afaik 19:17:50 <dgilmore> +1 from me 19:17:59 <mitr> +1 19:18:04 <mattdm> #proposal steve looking for comaintainers for all his packages. we'll make an annoucement and use the fesco ticket to coordinate 19:18:17 * pjones +1 19:18:34 <notting> +1 19:18:41 <nirik> ok. I think it might be good to do the perl ones before any announcement... just so there's less chaos. 19:18:42 <t8m> mattdm, that is not the same as in the ticket 19:19:10 <nirik> I can ping psabata about that. 19:19:10 <t8m> mattdm, I read that he wants to be only comaintainer and give up the primary maintainership 19:19:34 <dgilmore> t8m: agree 19:19:51 <dgilmore> that was my reading also 19:20:09 <mattdm> oops yes you are right. 19:20:12 <abadger1999> +1 nirik's proposal 19:20:13 <nirik> right, which takes a scmadmin to swap them... 19:20:33 <mattdm> #undo 19:20:33 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x2ca60e50> 19:20:54 <mattdm> oops that undid the topic. nice. 19:21:03 <abadger1999> I don't think proposals are actually meetbot commands :-) 19:21:07 <mattdm> i guess not. :) 19:21:09 <mattdm> #topic #1233 Nonresponsive maintainer: steve 19:21:14 <mattdm> soo. 19:21:42 <t8m> #agreed steve will be changed to comaintainer and the packages orphaned with the perl-* packages assigned to psabata (+7 -0 0:0) 19:21:44 <mattdm> #proposal steve looking for new maintainers and would like to remain comaintainer for his packages. We'll make an annoucement and use the fesco ticket to coordinate. 19:21:53 <mattdm> blah blah nevermind. :) 19:22:10 * mattdm is just trying to make the minutes look pretty 19:22:16 <t8m> OK :) 19:22:21 <nirik> shall we move on? 19:22:23 <t8m> yes 19:22:34 <t8m> #topic #1234 Close a loophole in the Nonresponsive Maintainer procedure 19:22:38 <t8m> .fesco 1234 19:22:39 <zodbot> t8m: #1234 (Close a loophole in the Nonresponsive Maintainer procedure) – FESCo - https://fedorahosted.org/fesco/ticket/1234 19:23:19 * abadger1999 agrees with notting 19:23:32 <mattdm> +1 that 19:23:33 <t8m> #proposal cvsadmins should be advised not to reassign packages without FESCo approval 19:23:43 <nirik> there's a case tho that's different... 19:23:48 * pjones +1 19:23:53 <abadger1999> +1 19:23:53 <mitr> Was this actually a systematic problem? I've had a cvsadmin ask for confirmation on a change recently. 19:23:58 <nirik> EPEL branches where the Fedora maintainer doesn't respond in a week. ;) 19:24:24 <mitr> +1 anyway, "advising" doesn't hurt 19:24:25 <nirik> mitr: I don't think it's at all widespread. There was another case a few years ago that some folks got mad about... 19:24:30 <pjones> mitr: I think it happened the once? But it's not like this proposal is a giant policy change. 19:24:31 <t8m> nirik, adding new branch is not reassignment 19:24:43 <dgilmore> nirik: right. I think a longer term way to do it is to have the logic in an app that takes the human error out 19:24:44 <nirik> t8m: true... 19:24:45 <nirik> +1 19:24:51 <t8m> +1 19:25:23 <dgilmore> im +1 to the proposal 19:25:23 <t8m> #agreed cvsadmins should be advised not to reassign packages without FESCo approval (+7, -0, 0:0) 19:25:32 <t8m> #undo 19:25:32 <zodbot> Removing item from minutes: AGREED by t8m at 19:25:23 : cvsadmins should be advised not to reassign packages without FESCo approval (+7, -0, 0:0) 19:25:38 <nirik> is someone going to mail them about this? ;) 19:25:39 <t8m> #agreed cvsadmins should be advised not to reassign packages without FESCo approval (+8, -0, 0:0) 19:25:51 <dgilmore> nirik: I can mail them 19:25:52 <t8m> (notting +1 from ticket) 19:26:20 <t8m> #action dgilmore will mail cvsadmins not to reassign packages without FESCo approval 19:26:21 <nirik> dgilmore: cool. and perhaps close that releng ticket related to this? 19:26:30 <dgilmore> nirik: yep 19:27:03 <t8m> we have two more open tickets that were without the meeting keyword so I forgot to add them to agenda, do we want to discuss them< 19:27:35 * abadger1999 has time if others have the will ;-) 19:28:09 <nirik> sure? 19:28:22 * pjones in general says defer 19:28:24 <t8m> on the other hand I don't know if the interested people for for example the Gnome update are here 19:28:45 <pjones> abadger1999: it's not about having time, it's about interested parties having a chance to voice their point of view in the meeting. 19:28:53 <abadger1999> <nod> 19:28:59 <abadger1999> no worries there. 19:29:09 <nirik> the gnome update one I would personally defer anyhow. 19:29:13 <mattdm> discussion on the mailing list indicates that the gnome ticket should be deferred 19:29:14 <nirik> it's not even released yet 19:29:29 <t8m> ok, let's skip the gnome one 19:29:42 <mattdm> (there isn't sig consensus on whether that's even a think they want, yet) 19:30:09 <t8m> what about the change of the change process for Fedora.next? 19:30:33 <pjones> What's the ticket number we're talking about? 19:30:49 <t8m> #topic #1236: Change process for F21/Fedora.Next 19:30:59 <t8m> .fesco 1236 19:31:00 <zodbot> t8m: #1236 (Change process for F21/Fedora.Next) – FESCo - https://fedorahosted.org/fesco/ticket/1236 19:31:42 <mattdm> pjones it was https://fedorahosted.org/fesco/ticket/1235 19:31:50 <nirik> IMHO, we should wait on that until the tech spec documents, once we hash those out we should file changes for the ones we are actually hoping to do, etc. 19:32:14 <nirik> and ask for any other non product/next groups to file as well. 19:32:16 <mitr> There actually already are non-Product Change proposals queued; dealing with them reasonably timely would make sense I think. 19:32:19 <nirik> (well, they could anytime I guess) 19:33:02 <dgilmore> I really don't think it hurts to have the Change request to have considerations for products 19:33:15 <dgilmore> i.e. they expect to to effect one product only 19:33:49 <dgilmore> or its a more wide reaching change and will effect all 19:33:50 <mitr> Structurally I think the current Change process is quite fine; the existence of product WGs would make "self-contained" (within a Product) Changes more frequent, with FESCo acking them by default, which is what we want anyway. 19:34:31 <mitr> As for expanding them to QA/releng/websites, no opinion. 19:34:46 <nirik> the only thing we might adjust is perhaps if a change is 'product specific' (new type), it just goes to that WG to get discussed/approved and we ack it like any selft contained. 19:34:56 <t8m> mitr, is within a product really self-contained? shouldn't it be approved by a product wg 19:35:07 <t8m> nirik, +1 19:35:20 <mitr> t8m: "self-contained" = "everyone affected by the Change is involved in doing it". 19:36:04 <abadger1999> nirik, t8m: +1 19:36:09 <t8m> mitr, but within product != "everyone affected by the Change is involved in doing it" 19:36:18 <t8m> necessarily 19:36:20 <notting> From reading the ticket, what would be a "blocks fedora.next" change? We haven't had things denoted that way on the past, even if they end up that way in practice 19:36:21 <mitr> t8m: yes 19:36:25 <mitr> t8m: So I would expect them to be self-contained, and we would probably want to exercise more restraing in overruling the WGs - but we do want even intra-WG Changes to be announced to _everyone_ on -devel. 19:36:38 <t8m> yes 19:36:40 <nirik> yep 19:36:47 <nirik> I think that part of things has worked well. 19:36:51 <mitr> notting: that's unclear to me as well. 19:37:12 <abadger1999> nirik: going to be interesting for a little while though -- we're going to have changes that are part of product development that affect packages not in any official product at first. 19:37:26 <abadger1999> but we'll figure that out as we go along. 19:37:30 <nirik> yeah. 19:37:38 <nirik> as we always do... muddle along as best we can. 19:37:41 <mitr> abadger1999: s/at first/always/ 19:38:09 <abadger1999> mitr: I think eventually we might figure out a way to have alternative repositories to draw from. 19:38:29 <abadger1999> but... that's a contingency plan for another discussion ;-) 19:38:31 <mitr> abadger1999: Maintainers of these repositories will still need to be told about changes. 19:38:41 <dgilmore> notting: something like the anaconda re-write that blocks the whole release 19:38:55 <t8m> #proposal defer to next week 19:39:45 <mitr> Proposal: Open up F21 for ordinary Change proposals _now_, and continue the conversation about adapting the process for .next in the mean time. 19:40:01 <dgilmore> mitr: +1 19:40:06 <notting> mitr: +1 19:40:09 <pjones> mitr: sure, we can take proposals any time, +1 19:40:16 <pjones> the question is when we can accept them :P 19:40:30 <t8m> mitr, +1 19:40:33 <nirik> sure. I thought we were already open as we already approved some. :) 19:40:42 <mitr> pjones: I meant "start FESCo acking/naking them now", to be clear. 19:41:20 <drago01> I somehow doubt this "everything is different we can't do anything" thing ... because I doubt that for f21 stuff will be *that* different 19:41:25 <abadger1999> +1 19:41:35 <mitr> (Note that this does not come with a proposed submission deadline; we can set one up later as well.) 19:41:36 <pjones> mitr: and by "ordinary" you mean self-contained changes, or everything? 19:41:51 <t8m> mitr, are you +1 for yourself? 19:41:56 <abadger1999> drago01: +1. If we try to take too big of a step, we won't ever get an f21 out ;-) 19:41:58 <mitr> t8m: yes, for the record 19:42:06 <drago01> abadger1999: exactly 19:42:06 <pjones> (I'm actually +1 either way, but I'd like some clarity in the proposal.) 19:42:46 <t8m> #agreed Open up F21 for ordinary Change proposals _now_, and continue the conversation about adapting the process for .next in the mean time. (+6, -0, 0:0) 19:43:01 <mitr> pjones: I'd actually be fine with discussing absolutely everything now; I thought it would make sense to hold on with things that would obviously be affected by the Product-specific process changes (... which is I suppose unclear). 19:43:46 <t8m> #topic Next week's chair 19:43:54 <t8m> anybody wants it? 19:44:34 <nirik> I guess I've not done it for a bit... 19:45:38 <t8m> #action nirik will be the chair next week 19:45:44 <t8m> #topic Open floor 19:45:58 <t8m> Anything for open floor? 19:46:14 * nirik has nothing. 19:46:28 <mattdm> also nothing 19:46:29 <nirik> oh... did we want to come up with a new deadline for tech specs/docs from working groups? 19:47:07 <t8m> nirik, do you have some concrete date in mind? 19:47:54 <nirik> Mar 3rd? 19:48:48 <t8m> #proposal FESCo expects the Tech specs/docs from working groups by March 3rd. 19:49:22 <nirik> Or I guess we could just say "as soon as possible"... dunno what works best. 19:49:30 <nirik> +1 19:49:33 <t8m> +1 19:49:44 <notting> +1 19:49:51 <abadger1999> +1 19:50:02 <abadger1999> and +1 to the asap comment too ;-) 19:50:07 <mitr> +1 19:50:24 <dgilmore> +1 19:50:37 <mattdm> +1 to both 19:50:38 <t8m> #agreed FESCo expects the Tech specs/docs from working groups by March 3rd at the latest (+7, -0, 0:0) 19:51:05 <nirik> will someone tell all the liasons that? 19:51:16 * pjones +1 19:51:30 <t8m> I'd expect the liaisons to read the FESCo meeting minutes :) 19:52:32 <nirik> how about we update the ticket for weekly reports? as they are all on it. ;) 19:52:50 <t8m> nirik, OK, I can do that 19:52:56 <nirik> cool. thanks 19:53:08 <t8m> #action t8m will update the weekly reports ticket with this request 19:53:31 <t8m> if nothing else comes up in a minute I'll close the meeting. 19:55:10 <t8m> #endmeeting -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
