18:01:58 #startmeeting FESCO (2014-02-12) 18:01:58 Meeting started Wed Feb 12 18:01:58 2014 UTC. The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:58 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:59 #meetingname fesco 18:01:59 The meeting name has been set to 'fesco' 18:02:01 #chair abadger1999 dgilmore mattdm mitr mmaslano notting nirik pjones t8m sgallagh 18:02:01 Current chairs: abadger1999 dgilmore mattdm mitr mmaslano nirik notting pjones sgallagh t8m 18:02:02 #topic init process 18:02:08 Who's here? 18:02:21 * mattdm is here 18:02:35 * abadger1999 sees pjones, t8m said hi before the meeting started. 18:02:41 .hellomynameis sgallagh 18:02:42 sgallagh: sgallagh 'Stephen Gallagher' 18:02:47 .hellomynameis kevin 18:02:47 hi again :) 18:02:48 nirik: kevin 'Kevin Fenzi' 18:03:12 Hello all 18:03:42 dgilmore, You around for fesco meeting? 18:04:01 #topic New FESCo 18:04:06 https://lists.fedoraproject.org/pipermail/devel-announce/2014-February/001300.html 18:04:22 * dgilmore is here 18:04:28 elections are over and we have just a little turnover. 18:04:29 welcome dgilmore! 18:04:37 Thanks to mmaslano for her service and welcome to dgilmore 18:04:38 thanks mattdm 18:04:41 welcome 18:05:18 dgilmore: Welcome back to FESCo. Did you miss us? 18:05:20 I can adjust the list membership for new and departing members. 18:05:23 dgilmore, sgallagh, mitr, and myself were elected for this term 18:05:38 let's not forget the mailing list :) 18:05:55 nirik: Excellent. There's also: trac permissions and wiki pages. 18:06:01 nirik, I suppose mmaslano should stay as she is the liaison for Stacks 18:06:06 #info Thanks to mmaslano for her service and welcome to dgilmore 18:06:06 https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee https://fedoraproject.org/wiki/Extras/SteeringCommitteeHistory 18:06:20 #action nirik to take care of the mailing list switch 18:06:21 nirik, stay on the fesco list 18:06:43 t8m: We'll discuss and vote on that later. 18:06:50 t8m: yeah, there's a ticket on that, but sure. 18:06:52 (as part of a general liason on fesco list) 18:07:09 Anyone know of other wiki pages that need updating? 18:07:22 I'll take care of the wiki update and trac permissions. 18:07:23 sgallagh: sure i missed FESCo :) 18:07:28 abadger1999: I assume you mean limited to FESCo? ;-) 18:07:54 #action abadger1999 to take care of updating trac and the 2 fesco wiki pages 18:08:07 Thanks abadger1999 18:08:07 sgallagh: Yes ;-) 18:08:19 #topic #1221 (Product working group activity reports) – FESCo 18:08:20 .fesco 1221 18:08:21 abadger1999: #1221 (Product working group activity reports) – FESCo - https://fedorahosted.org/fesco/ticket/1221 18:08:52 I think this week the summary is "very little group activity as a lot of people were running around to conferences" 18:08:57 18:09:06 so, next deliverable is due monday? we may have to move that out... I don't think any of the groups have much yet. 18:09:08 There's was a little activity that would have been talked about last week. 18:09:21 nirik: Yeah, we knew that deliverable was ambitious 18:09:25 #info very little WG activity as a lot of people were running around to conferences 18:09:32 yeah. 18:09:50 nirik: I think cloud at least can *start* with our deliverables. 18:09:51 What was our deliverable for next week? It wasn't the schedule estimate, was it? 18:10:31 sgallagh: did we have a schedule for that? 18:10:38 (actually dgilmore already kicked off the question with fedora legal about our obligations for compliance with updates images) 18:10:49 abadger1999: I don't remember what the deliverable was offhand. 18:10:54 "The second deliverable should be a list of necessary changes from existing Fedora procedures needed to release the product. This should be ordered to show what things depend on other changes and at which point the changes will mean that we can no longer produce the current type of Fedora. This will allow us to identify the resources needed by what teams in order to implement the plan and at what p 18:10:54 oint we may need to have a longer than normal release cycle to do tooling work." 18:11:05 Right 18:11:06 I think that's what we (fesco) would be blocking on next but I don't know if we made a request for when they're due yet. 18:11:10 Ok, thanks nirik 18:11:57 so, ideally, each WG will come up with proposed deliverables, then we need to engage all the various groups to see how and if and when we can do those things.. 18:13:00 yeah. I volunteer to help coordinate the engagement part. 18:13:16 with emphasis on *help*. :) 18:13:29 #info fesco acks the notes on WG progress 18:13:40 #topic #1178 (Fedora 21 scheduling strategy) – FESCo 18:13:42 .fesco 1178 18:13:43 abadger1999: #1178 (Fedora 21 scheduling strategy) – FESCo - https://fedorahosted.org/fesco/ticket/1178 18:14:18 I'm not sure we can do this without the info from the last ticket. 18:14:25 #info FESCo needs the list of necessary changes from existing Fedora procedures needed to release the products. 18:14:53 Should we send a devel-announce notice about this? 18:14:58 * sgallagh volunteers, if so 18:15:02 sgallagh yes I think that's a good idea 18:15:09 #action mattdm to help coordinate the engagement of talking with other teams once we get the list of changes. 18:15:30 hi guys, sorry for being late - sick :( 18:15:45 jreznik: con-plague? 18:15:49 sgallagh: saying what? WGs: get us deliverables? 18:16:02 sgallagh: What's the topic of your message going to be? I got a little lost. sorry. 18:16:10 nirik: Laying out what exactly we need to know. 18:16:22 sgallagh, seems like... 18:16:28 Specifically, what constitutes "changes from existing Fedora procedures" 18:16:46 nirik and it also serves as a reminder to everyone not directly involved about what's going on 18:17:03 One of the things I noted from my conference experiences recently is that we've done a poor job of informing people about the WG efforts. 18:17:06 * nirik isn't sure how else to phrase that... 18:17:10 sgallagh, how many changes do you expect for f21 - or better how f21 is going to be different? 18:17:16 but sure, a status report announce would be good. 18:17:19 sgallagh: k. I think we specifically want the WG liasons to carry that to the WG's this week -- a general devel-announce post could be good for people who want to discuss it as well. 18:17:23 So having regular announcements talking about what they're working on (phrased as schedule reminders) can help with that 18:17:28 so they can be sure to show up at meetings. 18:17:34 abadger1999: yeah, I think that's right. 18:17:41 abadger1999 yeah 18:17:58 yep 18:18:13 sgallagh, yep, I like it but we don't have much that reminders tied to schedule now... 18:18:22 abadger1999: I think it also would be useful to remind people where the conversations are happening 18:18:29 18:18:35 i.e. have a footer that pints to the respective lists and IRC channels 18:19:01 maybe that status report could be resend to other places as a start? 18:19:10 I'll draft something up after this meeting and send it to the fesco list for editing. 18:19:48 jreznik: Hmm, maybe we should add devel@lists.fp.o as an explicit CC on the WG status update ticket. 18:20:01 #action sgallagh to send message to devel-announe that talks about where to discuss the initial list of changes to existing Fedora procedures 18:20:14 sgallagh, could you CC me too? I'd like to help as much possible 18:20:17 * nirik is leary of that 18:20:33 nirik: What part? 18:20:35 (Is this bikeshedding?) Do we really need to use -announce for something that people don't _need_ to take an action for? 18:20:35 sgallagher, yep 18:20:38 ccing the devel list. 18:20:50 sgallagh: Can I also put you on the hook for sending a message to the working group liasons in case they don't read this week's meeting log? 18:21:14 mitr: well, it's an announcement: here's the status, and next steps... 18:21:16 abadger1999: Sure 18:21:43 mitr: I think it's acceptable for things that people may want to take an active role in. 18:21:51 #action sgallagh to send what we need next from WGs message to liasons to bring to the next WG meeting 18:22:02 Even better than just CCing, some summary would be better with other tasks etc 18:22:22 jreznik: Well, ideally we should be summarizing those things with #info in this meeting 18:22:32 This week there isn't much to say, though 18:23:29 sgallagh maybe note that the PRDs are awaiting board approval? 18:23:44 they are? 18:23:58 They are 18:24:01 At my last count, I think they all have enough +1s to pass. 18:24:09 But they are being tabulated still. 18:24:15 ok. 18:24:45 also, the ticket is private 18:24:50 which means nothing is announced 18:24:58 which means none of them are officially approved. 18:25:15 * mattdm nods 18:25:16 * sgallagh nods 18:25:31 * jreznik is going to check the ticket 18:25:43 anyway, anything more to do here right now? 18:25:56 next ticket :) 18:26:27 #topic #1198 (Possible changes to Fedora EOL bug procedure) – FESCo 18:26:29 .fesco 1198 18:26:31 abadger1999: #1198 (Possible changes to Fedora EOL bug procedure) – FESCo - https://fedorahosted.org/fesco/ticket/1198 18:27:02 sgallagh maybe in your message you could note that we're really concerned first with the f21 schedule, and that things which affect that should be the focus of what we need right now. grander plans are welcome but can come later. 18:27:48 anyhow, I am not happy with having EOL bugs open past EOL. mattdm: perhaps you could explain to me the advantage of that? 18:27:57 mattdm: ack 18:28:55 nirik Yeah. People are noticing them after the EOL right now, and then end up unhappy about being unable to reopen them. 18:29:13 that's basically the problem statement. :) 18:29:26 I also don't like keeping them open. A grace period of 2-3 weeks, perhaps - but really not 6 months. 18:29:36 so, they don't notice the 1month out thing, they don't notice the eol thing until their bug is closed? 18:29:38 mattdm, that's because they ignore the first announcement 18:30:01 and they arent the reporter so they can't change version? 18:30:07 nirik or more often, someone else's bug. if it's their own bug, as we determined, they should be able to reopen. 18:30:22 I think they basically ignore anything that does not contain CLOSED whatever in it :) 18:30:35 in which case, keeping them open 6 months won't help 18:30:37 so leaving the bug open for longer time would not solve the problem 18:30:44 nirik, exactly 18:30:46 would be possible to say, that everyone can reopen CLOSED EOL bug? 18:30:48 or, they haven't upgraded to the new version yet, and can't easily test. 18:31:24 perhaps we could add to the wording: "If you see this bug on a current release and are not the reporter of this bug, please file a new bug and refer to this one" ? 18:31:27 jreznik yes, that would be possible. I don't know if it's possible to also force reversioning at that time. 18:31:28 t8m: +1 18:31:37 dont we update them all about a month before EOL stating to move to a neer release if the issue still exists? 18:31:46 * dgilmore could be wrong there 18:31:49 nirik, it's already there 18:31:57 dgilmore: we do 18:32:08 nirik doing that feels like asking people to jump through hoops 18:32:11 so they have the grace period 18:32:21 dgilmore it's a very limited grace :) 18:33:03 mattdm, but 99 percent of people reacts on the first message or close message 18:33:14 nirik Is your objection to the open-but-needinfo approach a) that it is confusing or b) that it feels inelegant? or both? 18:33:17 mattdm: 1 month is more than enough for a response, and we shouldn't be suggesting that it is OK to run EOL versions; it's not. 18:33:32 mitr No one is making that suggestion. 18:33:45 maybe include a link to "Clone this bug" in the EOL message ? 18:33:52 mattdm: it gives the perception that the bug can still be fixed in the eol release it's against. Which I think will be confusing to reporters 18:33:58 and 1 month clearly *isn't* enough for a response. this wouldn't keep coming up if it were fine. 18:34:00 clones bad. 18:34:26 nirik I think the NeedInfo message can really take care of that. 18:34:49 "f18 goes eol in a month" "f18 went eol" "oh, I still see this on my f18 machine here 5 months later, please push a f18 update to fix this" 18:34:51 mattdm, people react on warning, closure... 18:35:02 The frustrated demographic is largely people who *did* read the message but don't have the power to change anything 18:35:18 mattdm: honestly if 1 month isn't enough for a response, I think that speaks to a problem with the schedule. 18:35:18 mattdm: I think people are arguing that the time length (1 month) is enough. The problem is the status. People don't react to time limits, they react to the bug being closed. 18:35:20 mattdm, so let's fix this issue 18:35:22 nirik We can add that it's not possible, if that hepls. 18:35:25 mattdm: but you knew I would think that ;) 18:36:02 mattdm: but I think abadger1999 has a pretty good point there when he argues that the time limit isn't really the issue. 18:36:03 also as maintainer, if I look at my bugs I see a mix of eol ones in there... so I have to go construct a query to filter them out... 18:36:05 if you read message and you can't act - that's issue and that's what we hit 18:36:37 nirik but odds are pretty good that those EOL bugs are actually still valid. so it gives _you_ an extra chance too. 18:36:48 jreznik yes 18:37:03 can we vote on my proposal as it is, and then find something else if it doesn't pass? 18:37:07 nirik: clones bad even if the link has &version=rawhide (or whatever) automatically put in the URL ? 18:37:17 mattdm: If odds are that they're still valid, instead of closing them, we should move them to rawhide when eol hits. 18:37:19 I am +1 :) 18:37:22 let's fix that - everyone can reopen CLOSED EOL bugs would be first step 18:37:31 there really should be functionality to "reopen the bug with non-eol release" reachable to anyone not just packagers and reporter 18:37:36 mattdm: I'm not sure about those odds. If you never rebase to a newer version, maybe... 18:37:40 So, how about this: close at eol, then have another script trall them a month later and tell us how many had comments after the close? then look at those? 18:38:05 jreznik: and the version resets to a supported release? 18:38:16 nirik this query is hard. might be possible with the api. 18:38:39 mattdm, script could handle it 18:38:43 but I don't think the normal search has a way to look for "comment after event", just "comment after time". and "time" isn't instant. 18:38:44 nirik, yep 18:38:59 halfline: yeah, clones suck. They spew the entire old bug into the new one and add all the people to cc... even when/if it's just a 'this also affects' or 'can you ask maintainer x to do something related. 18:39:33 true 18:39:46 I got one recently that was like 100 comments and the clone had no clear comment why my package was added. I had to go comment and say "what do you want from me here?" 18:39:59 mattdm: "time-after-the-EOL-script-finished" would be good enough. The 0.5% of comments that would fall through... would fall through. 18:40:05 though in this case you would want all the old people and history around 18:40:15 but maybe "anyone can reopen" is indeed nicer if feesible 18:40:26 mitr except there might be a higher than normal percentage of comments that are quick responses to getting bug mail 18:40:40 I am pretty sure anyone can reopen. 18:40:40 * abadger1999 +1 to trying anyone can reopen 18:40:54 I guess I am ok with anyone can reopen. Might lead to some old junk, but thats ok 18:40:57 i mean, I am pretty sure "anyone can reopen closed:eol" is possible. 18:41:10 ... do we need to do technical research within this meeting? 18:41:29 do we want "anyone can reopen and has to change the version at that point"? 18:41:29 mattdm, could you check it and let me know? 18:41:44 mattdm, yes 18:41:46 mattdm: if we have 'anyone can reopen closed:eol (and it auto moves version to supported)" would you be ok with closing on EOL? 18:42:08 #action mattdm to check if it's possible to do the anyone-can-repoen-closed-eol 18:42:37 nirik yeah. I still like the needinfo way better but I think either is a big improvement 18:42:40 Okay, that it for discussion on this for today? 18:43:07 #topic #1197 (Procedure for suggesting/approving different Products and/or WGs?) – FESCo 18:43:09 .fesco 1197 18:43:10 abadger1999: #1197 (Procedure for suggesting/approving different Products and/or WGs?) – FESCo - https://fedorahosted.org/fesco/ticket/1197 18:43:10 do we want to vote to do it if the thing nirik just said is possible? 18:43:16 #undo 18:43:16 Removing item from minutes: 18:43:45 so the proposal... 18:43:48 we could vote or just see where we are next week? 18:44:01 we might also ask qa folks for feedback? 18:44:20 I am okay with waiting. I'm just itching to close the ticket. :) 18:44:36 Okay. 18:44:44 #topic #1197 (Procedure for suggesting/approving different Products and/or WGs?) – FESCo 18:44:44 understandable 18:44:51 .fesco 1197 18:44:52 abadger1999: #1197 (Procedure for suggesting/approving different Products and/or WGs?) – FESCo - https://fedorahosted.org/fesco/ticket/1197 18:45:13 sgallagh: Do you want to summarize the ml thread? 18:45:29 Not particularly :) 18:45:41 But I can try, yes. 18:46:26 In terms of how to deal with Products, Spins and Remixes, we have a lot of opinions (and a lot of emotion around it) 18:47:01 The most vocal voices were those representing the desktop spins. 18:47:24 Concern was that they would be shunted to an out-of-the-way portion of the website, never to be seen again 18:47:58 well, some concern was that they would just be dropped. 18:48:01 I'd suggest 1. keeping Spins for F21 as they are 2. See what comes out of the existing products for F21 3. only after that think about further policy for spins and new products 18:48:06 Recent developments on that front indicate that the Workstation product is interested in supporting the selection of alternative desktop environments provided that they support certain requirements. 18:48:18 t8m: I generally like that. 18:48:24 (such as being capable of operating under GDM) 18:48:59 Do we need to make any changes so that releng and QA are able to manage the spins + product workload? 18:49:03 t8m: I like that partially. I think we should change spins some for f21 too tho... namely perhaps: move the process directly to fesco instead of spins sig/spins wrangler. 18:49:04 Similarly, there is a suggestion on the list (that I like) that has many of the feature spins such as Electronics Lab or Games as optional install groups for the Workstation product. 18:49:28 * dgilmore almost thinks there should be a Alternatives WG or something like that that replaces the mostly dysfuctional spins SIG 18:49:39 sgallagh: do we know if the feature spin owners are ok witht hat idea? 18:49:47 I'd like for the Workstation WG to explore this further, as it may be a better solution than the spins. 18:49:49 dgilmore mitr has put a moratorium on creating more WGs :) 18:50:08 s/WGs/bureaucracy/, even 18:50:10 nirik: We do not. It took a while for the conversation to cool enough to start suggesting productive solutions 18:50:27 abadger1999 qa (well, adam, iirc) says that spins are not a significant qa burden 18:50:32 sgallagh: one thing that inode0 brought up to me in irc was how any of this would affect the multi-desktop live dvd. That seems to be very popular pressed-media for ambassadors. 18:50:39 and dgilmore can speak for releng 18:50:51 mattdm: because they don't test them unless they have spare cycles 18:50:57 sgallagh: Would we still be able to produce multi-dektop lives? 18:50:59 And I still think that a product/WG should be there to solve a specific kind of use, not an upstream or an internal organization need 18:51:00 abadger1999: Considering that media's popularity, it's kind of silly that it has never been an official image anyway... 18:51:06 sgallagh: perhaps we should engage those people directly if we can find them 18:51:22 mattdm: as to releng making them is not a lot of burden, removing them if they are untested is more of a burden 18:51:24 I leave it to jwb and the Workstation WG to figure out whether that can be incorporated there 18:51:32 "that"? 18:51:37 entirely not paying attention 18:51:46 jwb: I figured, hence why I pinged you 18:51:48 abadger1999: it's noteworthy that those don't work on UEFI machines at this time (though if time frees up after RHEL 7 stuff I might have a crack at it again.) 18:51:48 I think many ambassadors are really into promoting fedora as a bag of possibilities. 18:51:49 abadger1999, if ws product is going to be live, spins would be lives, it would be possible 18:52:15 dgilmore makes sense. so making them auto-removed if they don't work (for example) would reduce the burden. 18:52:20 sgallagh, i suppose you could either elaborate now, or i can read back in the logs later 18:52:24 mattdm: no 18:52:30 jwb: Basically, I'm leaving it up to your group to figure out how to deal with install media for alternative desktops 18:52:44 i.e. multi-desktop install media vs. per-desktop media. 18:52:44 there's other areas they are a burden... 18:52:49 sgallagh, that.... doesn't sound at all like something the WG is going to tackle? 18:52:49 pjones, multi desktop live should work on UEFI, DVD was scratches because of no support 18:53:06 sgallagh, we're focusing on the Workstation Product, not ALL DEs 18:53:10 mattdm: a tool to remove them would reduce the burden, tehr eis room for improvement 18:53:12 mattdm: well -- inode0's example was: You go to a linux conference and someone walks up to the fedora booth. They'll walk away with a fedora live image if your live image has the desktop env they want to run. Otherwise they won't. 18:53:12 jwb: I realize that 18:53:14 jreznik: right, the multi-install-image disks don't work 18:53:25 jreznik: you're right, my failure to make that distinction. 18:53:32 a) websites. Having to remove them if they are broken, readd them. Having to maintain a spins site, etc. b) some releng time just simply waiting for them to compose and move around all the bits they are. 18:53:35 sgallagh, so... uh, my answer would be "let the alternative desktops figure that out themselves" 18:53:53 * jwb is confused 18:54:07 mattdm: there is more burden on websites that QA and releng really 18:54:09 I think the solution to the multi-desktop dvd is to work with ambassadors and marketing on new message about exciting products. if that's not selling, then we need to go back to the products 18:54:21 jwb: Recent chatter on the Workstation WG seemed to suggest that alternative desktops would be supported as long as they implemented the Workstation API layer. 18:54:28 I didn't get much more detail than that 18:54:37 abadger1999 that's not what I see. What I see is that people grab whatever swag is on offer. 18:54:40 sgallagh: but that is perhaps unrelated to their spins. ;) 18:54:59 for multi live vs live for each spins - one reason why we do it are costs... it's cheaper to produce many copies of one big DVD, cheaper to distribute, easier to give to people at events 18:54:59 sgallagh, oh, that. sure. but that's a pretty damn big qualifier you left out from "alternative desktops" 18:55:11 Sorry 18:55:13 sgallagh: That's stronger than what I understood. 18:55:24 it should not take more then a fesco ticket and assigned liasion from fesco to form a WG 18:55:28 but I think the multi-de dvd is a separate issue and I should shut up about it now so we can get through the meeting 18:55:52 sgallagh: In the past they ambassadors would make some of the different livecds to offer up choice. which brought around the desire to offer up all in one 18:55:54 Viking-Ice: To form a WG, I agree with you 18:56:05 and I expect DVD would die soon, nice swag but in the future nobody would have dvd drive... 18:56:06 Viking-Ice it takes much less than that to form a SIG. 18:56:06 To build a product out of the Fedora Project, I think that requires more buy-in 18:56:25 sgallagh, really it's not like existing WG's have entirely sold that idea 18:56:27 well a product should be distinct enough from the others 18:56:31 mattdm: k. We'll need to have you and inode0 talk more then. 18:56:32 the WGs are more like a Project, and to form one of those by the current rules requires board approval 18:56:39 drago01: Yes 18:57:13 so, I think: a) we ask 'product' spins if they would be willing to drop their spin in favor of groups/setup in the workstation product, b) we move spins under fesco, where fesco takes the spins sig/wrangler roles, c) otherwise we keep things as is for f21 barring need for further changes in spins. 18:57:16 mattdm, how so are they more like a project 18:57:25 Viking-Ice see https://fedoraproject.org/wiki/Defining_projects 18:58:14 these are ( branded ) spins formed by a essentially SIG 18:58:24 nirik, how a) would be implemented? 18:58:27 same stuff different label 18:58:53 We're at 15 minutes and we have a lot of other tickets. 18:59:05 Votes to continue? Proposals to vote on? 18:59:10 the difference is a) more formal governance structure and b) actually, the top level approval is itself part of the difference. 18:59:11 I'll make a proposal 18:59:12 jreznik: groups that could be installed via command line or via gnome-software? 18:59:12 and it's not like any of the sub community have resources to dedicate to the current and future products so they are on the same boat as spins 18:59:21 nirik: I'd wayt with a) until the desktop@ conversation is clarified 18:59:29 abadger1999 I vote to move on. we need more discussion than we can do in this meeting. 18:59:34 nirik, what about live then? 18:59:50 nirik: my biggest concern with that plan is that we're not exactly the best model of decentralized control ever, so it'd be bringing a lot of work in to fesco. 18:59:55 * abadger1999 agrees with mattdm but waits a minute for sgallagh 19:00:08 mitr, why wait so you can ensure that another desktop oriented WG cannot come to existance? 19:00:22 Proposal: A WG can be formed from any SIG that wants to offer a liason to FESCo for approval. They can then petition for producing an official Fedora Product by bringing a formal proposal to both the Board and FESCo to determine if it is addressing a sufficiently-different problem space. 19:00:32 jreznik: well, those types of spins are more about a product/thing than a live... so you use the workstation (or whatever spin) and install them from there. 19:00:41 pjones: we at least meet regularly. 19:00:52 sgallagh, define sufficint different problem space 19:00:58 well, yes, but we have... issues letting people get on with their work. 19:01:03 we're somewhat terrible at it. 19:01:15 sgallagh: I might be alone but I don't like the criteria of different problem space. 19:01:23 nirik, for games spin etc. I'm really in favor of that, question was for DE spins 19:01:25 Viking-Ice: Intentionally left subjective. The sitting members should decide if it's too much overlap. 19:01:32 sgallagh, there is a difference between desktop audience and a workstation audience would you call that sufficient 19:01:33 I feel that we need to make products if there's sufficient community to support it. 19:01:36 jreznik: I wasn't talking about them. They would continue. 19:01:48 which might mean that we have products whose problem space overlaps considerably. 19:01:53 sgallagh: -1 at this point. We don't need enablers for more bureucracy. 19:02:01 pjones: yeah, but when you have spins where someone does all the work and can't get approved for 2 cycles, I think fesco would possibly do better than an absent sig. ;) 19:02:47 Viking-Ice: No, so that we don't institute something (e.g. desktops -> comps groups) that conflicts with what the Workstation WG and non-GNOME representatives agree to use as a mechanism. 19:02:58 abadger1999: Could you elaborate on your reservations about the problem space? 19:03:08 My point is that it doesn't really make sense for Fedora to compete with itself. 19:03:24 sgallagh: I think it sorta does. 19:04:03 at least for "alternative desktops" it already does 19:04:16 sgallagh: and it should be clear what to pick for what "I want a server so I pick the server ... I want to intsall it on my laptop so I pick workstation" etc 19:04:17 if you have 100 contributors who want to produce a product which targets one set of people. And 100 other contributors who want to produce a a product that targets the same set of people... 19:04:32 the question is whether fedora is placing more value on its products or its contributors. 19:04:40 abadger1999, then you will see advancement 19:04:50 At the end of the day, those who do the work have the ultimate say. 19:04:53 I would rather have those contributors producing competing products. 19:05:14 sgallagh, so you should not limit them if we want inclusive community 19:05:28 abadger1999: so, instead of 'different problem space' you would say 'viable resources' ? 19:05:34 nirik: Yeah 19:05:36 jreznik, abadger1999: At no point did I say that they can't or shouldn't work in Fedora 19:05:43 if anyone is willing to invest theirs own time for their own bureaucracy, why not? 19:05:45 I suggested that Fedora's *standard offering* should pick one. 19:05:50 sgallagh: ... and to be more constructive, we already have a lighter-weight process to form a SIG, and until the "become a product" conversation starts, the liaison is fairly unnecessary anyway 19:06:00 And then if the winds of change determine that the other one should become the default: switch. 19:06:01 nirik: if there's a threshold, it should be about people there to create and maintain the product 19:06:14 abadger1999: I sort of agree, but then I don't think we want 'here's our default: chooose one of these 16 things' 19:06:19 nirik, viable resources, prove quality 19:06:48 Okay, so, I guess we're doing this conversation here. :) 19:06:51 mitr: True enough. We can rephrase the liason part. 19:06:59 mattdm: good point. 19:07:14 sgallagh, "standard offering" are you referring to the wg outputs 19:07:14 * abadger1999 invokes cloture rule: Vote to conitnue now: 19:07:17 -1 19:07:19 can we really move on? I don't think we need to solve it at this time unless we want to drop the existing spins 19:07:20 abadger1999: well, and project resources too... 19:07:22 Viking-Ice: Yes 19:07:27 -1 19:07:31 abadger1999: +1 19:07:34 (this could continue on list) 19:07:36 I had a question in the ticket for the "low bar" side; I guess that could be recharacterized as the "viable resources side" 19:07:43 -1 (move on) 19:07:43 sgallagh, community produced products cannot be considered standard 19:07:50 nirik: yeah -- there's a lot to discuss, I think ml will be better use of our meeting time 19:07:58 that is -1 -> move on 19:07:59 t8m: yeah, I don't think we're making progress here. 19:08:05 Viking-Ice: That doesn't make any sense. 19:08:30 Need one more -1 to move on or 4 +1's to keep discussing. 19:08:33 They can be standard *within the Fedora Project* 19:08:35 i'd like to see some discussion of marketing and web site design in a any-number-is-okay world. 19:08:38 not now though. 19:08:45 that's what I want in the ticket or mailing list. 19:08:51 *shrug* -1 to continue now (what I'd really like to table this post F21) 19:08:54 sgallagh, if you form a wg that produces some product then it's a given that that products becomes standard or is it not? 19:09:15 #info Continue to discuss how to make new products on mailing list 19:09:24 #topic #1231 (Provenpackager request: averi) – FESCo 19:09:26 .fesco 1231 19:09:27 abadger1999: #1231 (Provenpackager request: averi) – FESCo - https://fedorahosted.org/fesco/ticket/1231 19:09:43 +1 from me. He knows his stuff and would make a great provenpackager. 19:09:44 mitr, best for you guys to settle this as fast as possible if an desktop WG is emerging to focus on the desktop audience not the workstation audience 19:09:55 +1 to PP for averi 19:09:56 racor had one -1 on ticket. 19:10:20 three was discussion with averi and for me it was enough that I'm willing to vote +1 19:10:28 *there was discussion 19:10:39 yeah looks like that was pretty well addressed 19:10:41 so +1 19:10:43 based on the recommendation of his sponsor, whom I trust on this matter, +1 19:11:19 I'm voting 0 simply because I haven't worked with him. 19:11:33 im +1 19:11:43 Viking-Ice: I haven't seen much to suggest that the "workstation" focus is being abandoned. I suppose if there were a group who specifically went to FESCo with "here, we want a $specific product" starting now, it would make sense to discuss, but doing so now in the abstract is just a waste 19:11:46 #info averi approved as a provenpackager (+1:6, 0:1, -1:0) 19:12:06 #topic #1229 (RFC: add WG liasons to FESCo mailing list?) – FESCo 19:12:08 .fesco 1229 19:12:09 abadger1999: #1229 (RFC: add WG liasons to FESCo mailing list?) – FESCo - https://fedorahosted.org/fesco/ticket/1229 19:12:13 because he has a good grasp of things and is willing to work with and understand others, his sponsors reccomendation is a plus 19:12:27 mitr: I think he means that he expects to see a separate Desktop WG from the Workstation WG come along. 19:12:29 historically, only current fesco is on the list and we're not supposed to use it anyway. 19:12:33 abadger1999: +1 to #1229 if you want to keep a record 19:13:04 #undo 19:13:04 Removing item from minutes: 19:13:16 Well, recently we did use it, and it was fairly useful I think 19:13:18 #undo 19:13:18 Removing item from minutes: INFO by abadger1999 at 19:11:46 : averi approved as a provenpackager (+1:6, 0:1, -1:0) 19:13:30 abadger1999: Why did we undo? 19:13:31 #info averi approved as a provenpackager (+1:7, 0:1, -1:0) 19:13:41 #topic #1229 (RFC: add WG liasons to FESCo mailing list?) – FESCo 19:13:56 sgallagh: sorry, just me not keeping up 19:14:01 mitr, well let me then solve that question for you, I want to form a desktop WG which will target desktop audience not workstation audience and deliver multiple desktop products as an result of that 19:14:05 So, there are two main things: a) automatic cc of all the tickets and b) possibly sensitive matters 19:14:06 right. it's typically only been for 'sorry, I will not make the next meeting' or the like. 19:14:32 Viking-Ice: ok 19:14:40 +1 to add the liaisons 19:14:40 Viking-Ice: we don't happen to be on that topic right now. 19:14:43 a can be solved by just adding the liasons to the explicit cc in trac. 19:14:53 to the mailing list 19:14:53 i think that was already done 19:15:01 +1 to adding to the mailing list 19:15:03 but I'm +1 to adding the liasons... we can always change it later if it's a problem. 19:15:04 I can be +1 to adding liasons so long as they know it's a private list and some matters may be sensitive 19:15:21 pjones, knew that just making the question "official" as asked 19:15:45 as for the "sensitive" matters can they be really sensitive? do we being voted into FESCo become somehow legally approved to see sensitive stuff? 19:15:47 * dgilmore has no opinion, being new I don't know the details of list usage and if its needed so 0 19:15:55 sure, +1 for adding them as long as people can tell me who they are and when to update them. 19:16:07 (or additional list admins added, thats fine with me too) 19:16:07 t8m: for legally sensitive matters, it should be passed to the board. 19:16:10 t8m: Well "sensitive" can mean "t8m was mean to me! Take away his packager rights" 19:16:29 sgallagh, that's theoretically the CWG, not FESCo 19:16:30 sgallagh, sure, but I suppose such stuff can be seen by the FESCo liaisons 19:16:33 in the distant past (many many years) there were private things on there... 19:16:40 t8m: sensitive would problably be more along the lines of I think personX is harassing other people but I don't want to put my name into the open as reporting him. 19:16:40 t8m: it doesn't happen often, but typically it's "two people aren't behaving like adults and we'd rather not embarrass them or us in public" ;) 19:16:45 jwb: Sure, I was just pulling an example out of the air 19:16:51 I'm +1 to having the liasons on the list 19:17:00 t8m: right, I don't have a problem with them knowing; I just want them to be informed about it. 19:17:01 It's more sensible than creating another list, anyway 19:17:06 pjones, sure 19:17:09 jwb: actually -- if it's take away his packager rights, it's fesco. 19:17:12 so anyway, I'm +1 19:17:24 jwb: if it's could you mediate this conflict? then it's cwg. 19:17:43 abadger1999: in the weeds man 19:17:48 abadger1999, if fesco removed packager rights without referring to CWG for mediation, then wtf is fesco doing 19:17:55 seriously, we don't need to be having this conversation 19:18:05 I think we're at 5 19:18:11 weeds, weeds all around weeds. 19:18:23 nirik, you do live in CO... 19:18:29 indeed. ;) 19:18:52 #info Adding liasons to fesco list passed (+1:7, 0:0, -1:0) 19:18:55 abadger1999: i think its six +1 and one 0 19:19:20 who all needs adding? 19:19:24 #undo 19:19:24 Removing item from minutes: INFO by abadger1999 at 19:18:52 : Adding liasons to fesco list passed (+1:7, 0:0, -1:0) 19:19:30 #info Adding liasons to fesco list passed (+1:7, 0:1, -1:0) 19:19:37 dgilmore: Thanks 19:19:50 #topic #1230 (Requesting FESCo address Cherokee logo issue) – FESCo 19:19:51 .fesco 1230 19:19:53 abadger1999: #1230 (Requesting FESCo address Cherokee logo issue) – FESCo - https://fedorahosted.org/fesco/ticket/1230 19:20:06 nirik, myself, mmaslano, pknirsch i believe 19:20:33 So -- the packager is onboard with this now. 19:20:34 ok, and any new fesco changes. 19:20:44 abadger1999: finally. 19:20:46 Proposal: FESCo asks the package maintainer to either remove the logos or drop the package, depending on their judgement. 19:20:48 (... and taking no other action) 19:20:49 nirik: mitr, +1 19:21:41 mitr: well, there's a number of other questions beyond just this package. 19:21:44 (For the record, this is what the upstream support does: https://github.com/cherokee/webserver/commit/965311bf0ff0f00556abfbc425fe2dc9c52f5533 . I don't think it matters for the proposal but perhaps some of you think differently.) 19:21:45 I'd somewhat prefer we took a stronger stance here. 19:22:13 mitr: I saw that and think it's very poor. But they did that before they agreed there was a problem 19:22:41 nirik: note that Fedora packager != upstream 19:23:01 mitr: *sigh* upstream doesn't really understand what's going on, do they? 19:23:26 At this point, I think upstream is being obstinate for its own sake 19:23:46 mitr: ah true 19:23:57 abadger1999: I suppose not. The very first real explanation happened in https://fedorahosted.org/fesco/ticket/1230#comment:30 (until then it was just a lot of noise and shouting from the European uneducated POV), which they may not even seen until today. 19:24:21 +1 to mitr 19:24:24 ... may not even have seen at all, to be precise. 19:24:25 In any case: Proposal: FESCo requests that the offensive logo be removed from the Fedora package within 14 days or else the package will be forcibly retired from Fedora. 19:24:49 sgallagh: -1 19:25:06 sgallagh: I don't think this is strictly necessary but it would be better than no proposal passing :) 19:25:06 But +1 to mitr's proposal. 19:25:18 I'm okay with the more relaxed version. if that isn't followed, we have a different problem 19:25:25 mattdm, +1 19:25:48 mattdm: We do have a followup problem, make no mistake :) 19:25:50 so, do we want to address the higher level questions first? 19:26:18 ie, do we feel this offensive content thing should be still in guidelines. If yes, do we feel this is one? 19:26:56 +1 to remaining in the guidelines although it is somewhat subjective to decide on it. 19:27:00 nirik, I think the answer to both questions is yes 19:27:08 Yes/Yes 19:27:12 I am also yes/yes 19:27:16 I feel it is a case of one. 19:27:39 (at least for me) but for the second question it really took some reasoning so I can understand why the maintainer did not react until recently 19:27:51 I'm not _altogether_ happy with the offensive content rule; I mean, we've had contributors from countries that were at war with each other in the past, so being "offensive" is such a trifling thing in comparison... but overall yes/yes 19:28:04 and +1 to t8m; explain, don't shout 19:28:18 * pjones also yes/yes. 19:28:47 t8m: yeah -- I can understand too. 19:28:59 mitr: yeah, but a couple hundred years of genocidal tendencies and outright racism isn't exactly the same thing as a war. 19:29:01 so, I guess if we agree on that, the next question is: does the "censored" art meet the legal bar (fedora legal would need to say there), if so, does it meet our bar. 19:29:08 nirik: yes and yes 19:29:44 nirik: "we already know yes"/ therefore the second is irrelevant 19:29:49 nirik: I think ref clarified that there is no legal bar for this specific issue. 19:29:53 nirik: I would think if legal is okay with it then its okay 19:29:59 there is a fedora legal issue. 19:30:05 It does not meet my bar for offensive. 19:30:08 https://bugzilla.redhat.com/show_bug.cgi?id=1060984 19:31:18 https://fedorahosted.org/fesco/ticket/1230#comment:10 19:31:22 At the risk of being crass, would we accept a pixelated picture of genitals as an icon? Particularly if it wasn't too difficult (like this) to recognize what is behind it? 19:31:22 I really think the 'censored' image is really poor. It is still somewhat recognizable to me. 19:31:39 "This particular immediate (FESCo) issue is NOT about RH Legal, but my personal views as a Fedora user and community member. It is directed at Fedora's published guidelines concerning acceptable content. " 19:31:58 and it makes me think "oh, here's a chrokee, but we are ashamed, so it's [ixelated out" 19:32:32 I really dislike the way upstream "resolved" the issue 19:32:32 nirik +1. I don't think this is sufficent. 19:32:48 the censored logo isn't sufficient. 19:33:04 Shall we call a vote on that? 19:33:06 I like that we should add a note about defamation to our counsel's file. 19:33:11 I think we should just drop it. 19:33:15 where's the direct url for the censored logo? 19:33:19 * mitr notes that the proposal was "remove the logo" 19:33:26 pjones https://raw.github.com/cherokee/webserver/965311bf0ff0f00556abfbc425fe2dc9c52f5533/doc/media/images/admin_handler_dirlist_ex-CENSORED.png 19:33:30 https://github.com/cherokee/webserver/commit/965311bf0ff0f00556abfbc425fe2dc9c52f5533 19:33:37 mattdm: mizmo_ volunteered at one point to create an acceptable one. mizmo_ is that still on the table? 19:33:42 sgallagh: no.. 19:33:44 sgallagh: it isn't 19:33:44 ... well, I think that pali can just handle that in an appropriate manner 19:33:48 she withdrew that offer 19:33:51 sgallagh: upstream poisend the well. 19:33:52 So they just scaled it down and scaled it back up again and now it just looks offensive from a distance? 19:33:57 no, not sufficient. 19:33:58 Ok 19:34:27 * mattdm thinks web servers do not need to ship logos at all. 19:34:34 Honestly replacing the logo would just be unnecessary offensive action 19:34:36 * pjones has to step out now 19:34:45 sgallagh: the bug says she withdrew her offer 19:34:53 proposal: package maintainer to remove offensive logo(s) and replace with something non offensive (but not the censored version). If maintainer refuses or 2 weeks pass, package to be retired from fedora and no longer shipped. 19:35:07 nirik: +1 19:35:12 nirik: +1 19:35:27 mattdm: in a similar vein, the logo file could simply be a transparent pixel until something more suitable was arranged. 19:35:39 nirik: +1 19:35:45 abadger1999: yep. 19:35:52 nirik: "and replaced"? why? Can we just drop the files? 19:35:54 abadger1999: That would be fine 19:36:13 mitr: presumably they're referenced in a "you should configure your website" page or something? 19:36:15 mitr: I don't know the workings of the server, if that works fine, but they may cause some issue/ 19:36:17 but I don't know. 19:36:18 mitr: I think we're assuming that it's easier to replace the file in-tree than hack around it 19:36:18 nirik: +1 19:36:21 * pjones really steps out. 19:36:35 sgallagh: Leave it up to the maintainer, then. We don't need to micromanage that. 19:36:39 If it's feasable to just remove thats fine to me. 19:36:45 remove or replace 19:36:57 sure. 19:37:10 mitr: +1 19:37:22 +1 to the proposal with remove or replace (instead of and) 19:37:29 +1 with the rewording 19:37:33 +1s all around 19:37:33 +1 to the updated proposal 19:37:40 +1 to updated proposal 19:37:41 +1 with t8m's rewording 19:38:15 +1 to updated 19:38:54 #info package maintainer to remove or replace the offensive logo(s). If maintainer refuses or 2 weeks pass, package to be retired from fedora and no longer shipped PASSED (+1:8, 0:0, -1:0) 19:39:08 we should leave this ticket open to track it 19:39:46 #info fesco notes that the upstream "censored logo" is also deemed to fall into the offensive category. 19:39:53 nirik: works for me. 19:39:57 #topic #1233 (Nonresponsive maintainer: steve) – FESCo 19:39:58 .fesco 1233 19:39:59 abadger1999: #1233 (Nonresponsive maintainer: steve) – FESCo - https://fedorahosted.org/fesco/ticket/1233 19:40:18 seems resolved already? 19:40:26 so, this got closed... but I am not sure I like how it was resolved. ;) 19:40:32 This is resolved. 19:40:50 the user submitted a scm request on bugzilla and it was processed to add them as a co-maintainer. 19:41:09 as far as I know steve is still unresponsive 19:41:18 k. Do we need to do anything else? 19:41:28 no 19:41:37 well... 19:41:39 nirik: That's a pretty clever workaround, I'll grant that... 19:41:40 doesnt deal with the unresponsive maintainer 19:41:45 a) should we tell scm admins to not do that. 19:41:52 But it's also almost certainly not something we should be allowing 19:41:54 b) should we still look at orphaning steves packages. 19:42:15 as an owner, he owns 165 packages: https://admin.fedoraproject.org/pkgdb/users/packages/steve?acls=owner 19:42:16 I'm not sure they followed our current (flawed) process 19:42:35 I also send him email directly a few days ago, with no answer yet. 19:42:49 a) yes because it leaves us with b) unanswered. 19:43:11 mattdm, +1 19:43:45 so, a is actually (finally) another case of a issue we saw a few years ago... where it was proposed only maintainers/comaintainers can submit scm requests for a package 19:44:30 on b) I'd say lets wait at least another week for steve to respond to direct email (since it's not clear if he got any others yet) 19:44:34 nirik, hmm, perhaps expect adding epel branches? 19:44:59 nirik, +1 to the b) answer 19:45:06 t8m: well, the policy there was a week I think... if no reply from maintainer process after a week. 19:45:42 nirik: That works for me for (b) 19:46:25 #info decide whether to orphan other packages owned by steve next week since it's not clear if the week since direct email was sent has expired. 19:46:39 yeah, http://fedoraproject.org/wiki/EPEL_Package_Maintainers has it as 1 week with no answer. 19:47:52 I guess I'd be ok punting a) for now, since we didn't expect to discuss it today... and open a new ticket on it? 19:47:55 (for next week) 19:48:05 and close this one 19:48:27 nirik, +1 19:48:33 +1 19:48:34 +1 defer 19:48:44 +1 yeah 19:48:57 I'll open the new ticket as part of post-meeting ticket updates. 19:49:07 (I'll note there's a ticket in infra about this, and it was punted from fesco -> releng -> infra and probibly falls under releng) 19:50:30 nirik: scm processing moved into releng 19:50:50 dgilmore: right, which is why I say it might be back under that... 19:51:34 mitr, sgallagh: okay to defer this? 19:52:09 Fine with me 19:52:33 abadger1999: yes 19:52:37 #info defered to next week 19:52:51 One last agenda item but it's big. 19:52:59 #topic #1179 (Interactions of the various Products) – FESCo 19:53:01 .fesco 1179 19:53:03 abadger1999: #1179 (Interactions of the various Products) – FESCo - https://fedorahosted.org/fesco/ticket/1179 19:53:57 I added one thing to discuss related to this to the ticket. 19:54:02 Shouldn't we have a hard stop after two hours? :) 19:54:07 abadger1999: so, the things you list... I think those would be things base might be good to define... since the products all use the same base 19:54:14 t8m: Then let's type quickly 19:54:21 Since we're about out of time for our second hour I propose other fesco members, add things you want to discuss to the ticket too. 19:54:24 * dgilmore hasn't yet had dinner and its almost 9pm 19:54:28 And we'll get back to this next week. 19:54:51 #topic Next week's chair 19:55:14 Volunteers? 19:55:14 abadger1999, I can do that 19:55:19 t8m: thanks 19:55:27 #info t8m to chair next week's meeting 19:55:31 #topic Open Floor 19:55:36 I had a quick item, but I know we are low on time. 19:55:43 Is this time slot still acceptable? 19:55:52 nirik: you have five minutes ;-) 19:55:53 dgilmore: this is mostly directed at you 19:55:58 I just got a bug asking me to add a timer unit... didn't we want to put those on hold until we had guidelines? 19:56:20 sgallagh: its fine for me unless im home in Australia and thats usually only a month or two of a year 19:56:31 nirik: I think that was the case. 19:56:34 it starts at 4am in Brisbane 19:56:47 but I can deal with that when it happens 19:56:59 abadger1999: ok, I will mention that in the bug then... I hope they didn't file too many others. 19:57:18 nirik: Beyond that, if they did so without following the mass-filing process... 19:57:18 perhaps we should do a devel-announce about holding off on timer units until the time is right 19:57:38 I have to leave now 19:57:43 #info we'll continue with current time for now (dgilmore is the one most inconvenienced, may have to adapt later) 19:57:50 Looks like 2 new ones: https://bugzilla.redhat.com/show_bug.cgi?id=991679 19:58:08 19:58:11 nirik, +1 to that devel-announce 19:58:54 nirik: https://fedoraproject.org/wiki/User:Johannbg/Systemd/cron-migration 19:59:12 I'll have to click a bunch of links to figure out what the status is 19:59:30 yeah, dunno. 19:59:36 If nothing else, I'll close in 60s 19:59:42 it doesn't seem like it would be too hard, but we should get it right before adding a bunch 20:01:17 #endmeeting