17:00:07 #startmeeting FESCO (2014-10-08) 17:00:07 Meeting started Wed Oct 8 17:00:07 2014 UTC. The chair is jwb. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:07 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:11 #meetingname fesco 17:00:11 The meeting name has been set to 'fesco' 17:00:11 #chair dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh t8m thozza 17:00:11 Current chairs: dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh t8m thozza 17:00:12 #topic init process 17:00:15 whee 17:00:18 :) 17:00:19 morning 17:00:19 hi 17:00:21 hi 17:00:24 .hellomynameis sgallagh 17:00:26 sgallagh: sgallagh 'Stephen Gallagher' 17:00:32 * mattdm blinks 17:00:36 .hellomynameis mattdm 17:00:37 mattdm: mattdm 'Matthew Miller' 17:00:43 how is it 1pm already? 17:00:53 no idea, but i'm already exhausted 17:01:08 Hello 17:01:52 dilmore is travelling to australia 17:01:52 i think we're just waiting for kalev ? 17:02:22 let's get rolling 17:02:23 hello 17:02:33 #topic Consider renaming "Change(s) freeze" and "Beta 17:02:34 deadline/accepted changes 100% complete" points 17:02:40 .fesco 1351 17:02:41 https://fedorahosted.org/fesco/ticket/1351 17:02:43 jwb: #1351 (Consider renaming "Change(s) freeze" and "Beta deadline/accepted changes 100% complete" points) – FESCo - https://fedorahosted.org/fesco/ticket/1351 17:02:52 this is a follow up from last week 17:03:03 i don't think there's much to really do here other than say good job? 17:03:32 yeah. 17:03:38 adamw: ^ anything else here ? 17:04:01 i still kind of liked the numbered checkpoints (mumble mumble) but no, i think it's fine 17:04:06 oh 17:04:15 there is the stuff at the end of my last comment about what exactly these points *mean* 17:04:47 "there's a lack of clarity as to whether these are the dates on which FESCo will check the Changes to see whether they have reached these statuses, or the hard dates by which they must have reached these statuses presumably with FESCo checking along the way" 17:05:00 i'd say the latter 17:05:39 * nirik nods 17:05:47 It should be the latter 17:05:49 it might be nice to be a bit more explicit about it, i guess. honestly i just find the whole Changes/Policy page to be not quite as clear and thorough as the old Feature process pages...but maybe everyone else finds the old stuff over-engineered :) 17:05:52 yes, the latter 17:05:56 I agree that the second sound more reasonable. 17:06:01 the question is whether it is actually but... 17:06:05 better than doing all the checking at once 17:06:12 i'll see if i can do a light edit which brings that out a bit more clearly 17:06:23 ok 17:06:30 of course, it kinda depends whether you really have a process for doing the checks... 17:06:46 * mattdm looks shiftily at jreznik 17:06:56 "fesco looks at them" is enough for your changes for now 17:07:10 I agree with jwb 17:07:38 i don't want this ticket to evolve into an over-engineered exercise in documenting every contingency possible. the changes are good, but they don't have to be perfect 17:07:47 ok, so the message should be 'your change should reach these states by these times, you may expect fesco to check in on progress at any time' 17:07:53 yep 17:07:57 nobody expects the fesco inquisition! 17:08:00 gotcha 17:08:23 anything else before we move on? 17:08:46 LOL 17:08:50 * jreznik is reading 17:08:55 i think it's ok for me 17:08:57 ha. 17:09:13 jreznik: for the record i didn't change any of your edits back, i just argued with them in the ticket comments :P 17:09:24 adamw: it's totally awesome you're doing the wiki editing, by the way 17:09:26 much needed cleanup 17:09:31 agreed 17:09:56 #info FESCo pats adamw on the back. Attaboy! 17:10:02 * jwb looks at jreznik before moving on... 17:10:04 kalev: definitely! it was amazing job 17:10:18 for the time when it's checked by fesco 17:10:21 quite. :) thanks! 17:10:43 usually, deadline is on tuesday, I send it to fesco for the first review next day (for this meeting) 17:11:15 right 17:11:37 jreznik: details details :) 17:11:41 ok, next topic 17:11:43 #topic FPC is not working 17:11:43 .fesco 1346 17:11:44 https://fedorahosted.org/fesco/ticket/1346 17:11:44 jwb: #1346 (FPC is not working) – FESCo - https://fedorahosted.org/fesco/ticket/1346 17:11:57 I apologize for only adding comments after this meeting started. 17:12:28 tl;dr version: I think we should be thinking hard about what would it take to achieve more automation, and only discuss governance/authority/division of responsibilities _afterwards_. 17:12:37 yes I was just going to note that I hadn't read all of those :) 17:12:59 mitr: and status quo until that point? 17:13:01 mitr: I can definitely see where you are coming from there... ;) 17:13:27 so i'm kind of angry with this ticket 17:13:27 mattdm: With the assumption that the hard thinking would take no more than a month, yes. 17:14:01 you are all focusing on the technical aspects, which is fine, but none of you are noticing the fact that it was done without CC'ing anyone from the FPC or even giving them a heads up 17:14:35 * nirik nods. I talked with them after the fact. 17:14:43 i really dislike this trend 17:15:04 ok we could say that this was a mistake, but does that make the ticket invalid? 17:15:12 in my opinion, yes 17:15:20 it's exactly the opposite of how fedora should be operating 17:15:26 fesco doesn't solve things top down 17:15:40 and there was no discussion with the ACTUAL GROUP BEING DISCUSSED 17:16:49 I agree that was bad. 17:17:10 even if we ignore that entire aspect, what is fesco supposedly going to do here? 17:17:44 rip up the FPC and replace it with... what? because i know fesco doesn't want to do that. 17:17:45 there are concrete proposals which we could approve or reject 17:17:51 no, there aren't 17:17:57 So yes, we failed in ensuring they are CCed, and we really should do better. OTOH, pragmatically, if we closed this ticket now on principle, we would probably want to immediately open a new one and copy most of the comments. 17:17:58 yes they are 17:18:08 mitr, +1 17:18:10 there are proposals made by fesco members that have had NO discussion with the people they impact 17:18:21 s/non fesco members/ 17:18:30 They are still proposals. 17:18:43 this is absurd 17:18:49 as I said last time - my intentions were not to do ticket, I just used already opened one and really, I wanted to discuss that proposal in advance with everyone ahead... sorry for rushing it... but I still think what I wrote fits new Fedora model 17:18:51 jwb: Don’t forget this also impacts the ≥1000 other packagers. 17:18:56 you want to approve something that only fesco has discussed? 17:19:05 and force work on people without even talking to them? 17:19:25 jwb: I really don’t think we were at the point of approving anything today. 17:19:32 where we are saying that we want to approve things just now???? 17:19:43 why are proposals being made then? 17:19:52 using words as absurd etc. does not get us anywhere anyway 17:20:19 the proposal, as stated, is to split it between fesco and the WGs. nobody has talked to the WGs to see if that's even something they want 17:20:28 why are we discussing this? 17:20:32 we could agree to finally discuss this with FPC and WGs 17:20:36 *first 17:20:39 that's backwards 17:20:39 And honestly, I’d rather have the subject line of “FPC is not working” in the fesco tracker than in a -devel discussion. All this bad stuff has the silver lining that we can now start a reasonable public discussion with a better title. 17:20:51 jwb: We do know that env&stacks wants this for example. 17:20:53 * nirik is -1 to the proposals in the ticket in general if it matters for any further discussion 17:20:57 I think originally FPC was just one person -- the fesco at that time appointed spot to take care of packaging guidelines 17:20:58 we are discussing what we could ask the people which proposed the things to do 17:21:01 and he grew the fpc around him to help wit hthe task 17:21:07 at least that's what I've heard, I wasn't involved with Fedora back then :) 17:21:17 kalev, I think you're basically right 17:21:17 kalev: that's accurate. 17:21:19 so what I think it would take now is for someone to take on the project of more automation, or whatever else is needed there 17:21:20 jwb: And I think Workstation was asking for this as well. 17:21:23 and then fesco would give them the authority to do that 17:21:30 how about we open a discussion about pain points and possible help on the packaging list? 17:21:33 mitr, um... no 17:21:41 the Workstation WG has not discussed this 17:21:50 jwb: at least I was able to talk to base and stacks... really, my excuse is poor and reacted more like bull with red flag when I saw this ticket... on the other hand, sometimes fesco is able to decide in one hour :) 17:22:11 nirik: s/packaging/devel/ 17:22:11 IMHO the topic was really badly chosen but that does not invalidate the ticket completely 17:22:21 kalev: there is work being done on that... there's work around updating the review process and making it much more automated.... it's just not in a stage where it's ready to do or aprove or anything. 17:22:40 mitr: I suppose... packaging is where the FPC folks all hang out, but devel would be ok with me too. 17:23:03 one thing that fesco could do is point out pain points, and ask the fedora project leader to find someone to work on these, part time 17:23:13 nirik: packaging is where most of the others don’t hang out I think. 17:23:24 so to fix my mistake, I can bring the topic to more broader discussion on the lists and make sure everyone involved is on the same board 17:23:37 kalev, +1 17:23:42 wait 17:23:50 why are we now asking the FPL to go solve this? 17:23:50 also, Note: FPC has added one new member already at the last meeting. 17:24:06 you guys are really blowing my mind here 17:24:21 proposal: close ticket, find someone to facilitate meetings between current FPC and other stakeholders (Env & Stacks, Base WG, others?) 17:24:29 stop pushing things up the stack and start having broad discussions as jreznik and nirik have suggested 17:24:29 mattdm, -1 17:24:35 mattdm, +1 17:25:04 mattdm: -1. Less transparent, and all 1k packagers are stakeholders (though arguably we don’t want 1k people participating in a thread?) 17:25:06 mattdm: if agreed on, I'll take care of it 17:25:13 I'm not sure we need a facilitator until we have a discussion about who should be involved and where pain points are? 17:25:16 kalev: I'm not sure that it's a one person kind of job 17:25:19 nirik, +1 17:26:23 nirik: okay. someone to make sure that that discussion gets opened and happens in a way that doesn't set it up for failure and fighting? 17:26:32 sounds like "facilitator" 17:27:24 ok, so someone to post to devel? or you mean something above that? 17:27:56 nirik: I think both post to devel and help make sure that there's followup 17:28:15 mattdm: yep 17:28:16 alright. fine with me if someone wants to do that. ;) 17:28:18 shephard, liasion, moderator, facilitator, host, etc. pick a word 17:28:37 jreznik just to be clear it sounds like you're volunteering, right? :) 17:29:00 I think the post to devel should be done by the people who opened or at least partially agree with the points of ticket 17:30:07 t8m: I kinda don't. I know number80 means well with this, but I think that might set the wrong tone given the ticket title 17:30:21 mattdm: Yeah. 17:30:24 jreznik had the proposal. he seems apt to lead the discussion 17:30:26 I think it's clear we do need to have more active FPC folks so meetings have quorum, we might need to look at bundling guidelines to make them easier/faster. For things like golang I think we need to get more people interested/expert in those to help with drafting/explaining. Which is not easy. 17:30:29 mattdm: I can, at leat help 17:30:46 jreznik: yes not going to leave you _alone_ to hang :) 17:31:08 nirik, I think that splitting the parts of the guidelines that affect only particular groups to them is another good thing 17:31:32 what might help for posts would be to take a postive tone... "How to improve packaging and FPC" , etc 17:31:32 nirik: interested/expert - that's the main part of all discussion and it's definitely not easy at all 17:31:33 let's not try to come up with a solution in this vacuum here though 17:31:33 nirik: I tend think the “strict no bundling” philosophy will need to die (not because it is bad but because we can’t sustain it), and that will unblock a lot of the progress. 17:31:53 t8m: I am strongly against that for packages in the main collection. 17:31:59 since we already agreed that we're in an (albeit unintentional) vacuum of the people who need to be included. 17:32:19 I'm perfectly fine with something like the playground group having different guidelines set by the stacks and env group tho 17:32:26 nirik, t8m, mitr: we aren't solving the guidelines in this meeting. 17:32:36 move that discussion to the lists 17:32:38 * nirik stops, waits for disucssion on list. 17:32:46 OK. So, proposal: jreznik to open discussion on devel@ ? 17:32:51 +1 17:32:52 yes, +1 17:32:53 nirik, why people which are uninterested in golang should decide things about particular things that do not really affect anything else than golang??? 17:32:54 +1 17:32:57 +1 for the record 17:32:58 but nevertheless 17:33:06 +1 17:33:07 mitr: +1 17:33:09 +1 to that 17:33:16 t8m: because “do not really affect anything else" is very rarely true. 17:33:17 mitr: re bundling, I agree; it's basically sending a signal that it's better to reimplement code, instead of sharing code by coping files 17:33:29 t8m: they are trying to figure the best and most maintainable way to sustainably package things... 17:33:53 okay okay okay y'all :) 17:33:55 #agreed jreznik to open discussion on devel@ (+1: 7 0:0 -1:0) 17:34:05 #action jreznik to open discussion on devel@ 17:34:07 moving on. 17:34:13 #topic Bash scripts should rely on bash explicitly 17:34:13 .fesco 1352 17:34:14 https://fedorahosted.org/fesco/ticket/1352 17:34:15 jwb: #1352 (Bash scripts should rely on bash explicitly) – FESCo - https://fedorahosted.org/fesco/ticket/1352 17:34:15 adding to my todo's for tomorrow 17:34:55 so this ticket is expliction not about switching shells 17:34:56 which helps 17:34:57 I basically agree with what mitr said in the ticket 17:35:11 i tend to agree with mitr as well 17:35:13 Personally, I'm in the camp that any script using bash-isms that isn't doing #!/bin/bash is a bug. That said, so many things are doing this that it's spitting at a hurricane to try to change it now 17:35:35 * nirik nods. I am -1 to filing a zillion bugs on this and asking maintainers to deal with it. 17:35:55 * kalev nods. 17:35:57 I am +1 to nirik's -1 17:36:13 could simply send an email asking them to review. it would be a token effort at best 17:36:28 I don't think it any positive effect right now. Especially when nobody is really planning to switch the default shell in Fedora 17:36:37 Proposal: Ask Rahul to socialize the intended interpreter change instead of trying to make it policy. 17:36:52 socialize? 17:37:03 do we see us using bash as /bin/sh in 2 years? if it's a yes, then I don't see much point in filing tons of tickets fix this up. 17:37:19 jwb: I really don't want people with limited time (i.e. limited ability to follow the discussion and the aspect of complete voluntarity) spending any time on this. 17:37:24 * nirik is with jwb. socialize? 17:37:32 sure, it's technically a bug, but it's not something that's going to affect the distro in 2 years, so no point in trying to solve it here 17:37:39 sgallagh: If a bug exists but there is no way to notice it by observing the behavior of the system, is it still a bug? But if someone were interested in automating away this bug that would be fine with me. 17:37:44 mitr, which is why an easily ignored email seems fine? 17:37:50 "socialize" as in make a case in upstreams for doing this 17:37:53 mitr: I agree. My suggestion of a SHOULD was to mean if a maintainer decided to do it, great for them, but if not, no bggie 17:38:05 sgallagh, i'd rather just say "push this discussion upstream" 17:38:07 sgallagh: "make a case in upstreams", sure. 17:38:11 If a team of people including a proven packager wanted to organize a collective effort to do this, I guess I wouldn't say they couldn't. But I don't think we should worry about it. 17:38:15 mitr: Honestly, I can't see that it's worth the effort spent automating it 17:38:28 jwb: Fine by me 17:38:32 mattdm, right. they can go do that all they want 17:38:35 sgallagh: I’d expect it to be comparable with automating sending the emails :) 17:38:46 yep, if rahul wants to work with upstreams I would not forbide him :) but this is certainly not something Fedora package maintainers should spend their valuable time on 17:38:47 mattdm: I'd rather not have downstream patches carried by the distro just to change the interpreter. 17:39:02 jwb: I have seen people who do everything someone writes into a bugzilla ticket without thinking about it critically, I’d expect this to happen for mail as well. 17:39:12 kalev, +1 17:39:24 kalev: true 17:39:26 mitr, that sounds like an entirely different problem 17:39:33 mitr: Where can we find these people. I have over three dozen bugs that have to my knowledge never even been read... 17:39:56 so is the proposal to ask rahul to work with upstreams on this? 17:39:58 sgallagh: I have conveniently completely forgotten who it was ;-) 17:40:19 jwb: yes, that would be my suggestion 17:40:24 jwb: I'd be fine with that. 17:40:25 jwb: That sounds like a reasonable rephrasing 17:40:30 +1 to that. 17:40:33 jwb, +1 17:40:37 +1 17:40:45 Proposal: Ask Rahul to work with upstreams to resolve this issue rather than patching it downstream 17:40:56 * jwb counts the above +1s 17:40:59 +1 17:41:01 +1 17:41:03 +1 17:41:19 +1 17:41:23 +1 17:41:23 mattdm, ? 17:41:30 +1. And along the lines of the above: if rahul wants to maintain a list of packages with checkbashisms failures _outside_ of bugzilla and use that in an effort to work with upstream, that's okay 17:41:37 sorry writing long thing :) 17:41:53 that's okay in fedora wiki or somewhere 17:42:14 mattdm: Sure. 17:42:18 sure 17:42:26 #agreed Ask Rahul to work with upstreams to resolve this issue rather than patching it downstream (+1: 7 0:0 -1:0) 17:42:59 #info a list of packages with checkbashisms failures can be kept outside of bugzilla to facilitate the upstream effort 17:42:59 so what about about cases where the problem is in our patches or added scripts? 17:43:13 then we're the upstream and it makes sense to file tickets in rhbz 17:43:21 yeah, that seems like a common sense bug 17:43:31 do we need to codify common sense? 17:43:38 jwb: sometimes? 17:43:51 because the only thing about common sense is how it isn't common? 17:43:55 I could be splitting hairs and restrict this to patches/scripts that can be reasonably used outside of Fedora, but won’t :) 17:44:03 jwb: thats such a common saying. ;) 17:44:05 #info if fedora packages are the upstream, it's okay to file bugs 17:44:13 okay I'm done :) 17:44:26 i do not really think it makes much sense there either without actually finding someone to fix these "bugs" 17:44:42 it can't hurt 17:44:48 worst case, the bug is ignored 17:44:54 best case, the maintainer fixes it 17:45:00 and the bugs should be relatively low in number 17:45:15 moving on 17:45:23 #topic deprecate fedora-release file 17:45:24 .fesco 1354 17:45:24 https://fedorahosted.org/fesco/ticket/1354 17:45:25 jwb: #1354 (deprecate fedora-release file) – FESCo - https://fedorahosted.org/fesco/ticket/1354 17:45:34 * nirik put his 2cents into the ticket. 17:45:37 neither of the people that should be taking to each other about this are present today 17:45:58 my take here is that we should have some kind of documentation that says which file apps should use to figure out the fedora release name and number 17:46:04 apparently it's no longer /etc/fedora-release 17:46:18 jwb: in this case I think it's enough of a "distro api" that it isn't _just_ a package maintainer thing 17:46:21 I think the man page is a good idea 17:46:21 but I've no idea how to add the documentation, beyond adding man pages 17:46:36 also to explain what should be used (preferably) 17:46:41 thozza: +1 17:46:49 well, it's going to be a slow process, but we can ask upstreams to switch when we see them using the old one... 17:46:57 kalev, thozza , +1 17:47:07 Honestly I don't think this is a big deal. Most software I've seen is looking in /etc/redhat-release anyway 17:47:11 but there's 0 reason to override the maintainer and make this depreciated now before the new one is popular/used. 17:47:14 which we still do ship 17:47:32 kalev: AFAICT /etc/fedora-release works perfectly fine. Or doesn’t it? 17:47:46 mitr: it does. 17:47:48 kalev, i don't think that's apparent 17:47:52 redhat-release is a link 17:47:54 I think the point to do this would be if we decide to get behind the proposal of a system with an empty /etc except for deviations from default config. 17:48:00 mitr: its downside is that it's a fedora only file 17:48:01 anyhow, no point here. save 4k? 17:48:02 Which we are a million years (give or take) from doing 17:48:05 i think it's apparent that systemd invented a new file format and it could be used 17:48:05 is this about /usr/lib/os-release and the associated symlink, from upstream systemd? 17:48:31 kalev, mattdm: Anyone checking /etc/redhat-release will likely have a program/script doing tons of other distribution-specific stuff that isn’t addressed by this. 17:48:33 randomuser: no 17:48:38 it's about our /etc/os-release 17:48:51 * randomuser nods, will read more background 17:49:12 I think this ticket tries to solve a problem that didn't happen yet 17:49:17 nirik: the systemd proposal is for us to make /etc/os-release a symlink pointing into /usr/lib 17:49:23 because os release is not really configuration 17:49:24 thozza, yes. in a poor manner 17:49:28 thozza++++++++++++++++++++++++ 17:49:37 mattdm: where is that? 17:49:51 nirik: lennart mentioned it on devel list, I think? 17:49:53 Proposal: Close the ticket 17:49:54 * nirik would really like it if there was proposals for the systemd stuff, but mostly they just push an rpm with it changed 17:50:11 thozza: Yes. “We have designed /etc/issue for you; oh wait; /usr/bin/lsb_release; oh wait, no, /etc/os-release“ isn‘t really going to make ISVs all too happy to keep following us as we change our minds. 17:50:18 nirik: yes. this one obviously needs coordination 17:50:44 As if that symlink made things clearer… 17:50:49 mitr: yes, I think we should probably carry all of them basically forever, but give guidance which one is the preferred cross-distro method to use 17:50:56 mattdm, nirik: it wasn't a proposal. it was a "we did this" 17:51:12 * nirik doesn't have such a link here... 17:51:18 http://0pointer.de/blog/projects/os-release.html 17:51:19 kalev: Then my guidance is to call an API and not read _any_ files. If we don’t have an API (which we actually do), write one. 17:51:27 anyhow, if the contents are the same and it's coordinated with fedora-release thats fine. 17:51:34 they aren't the same 17:51:44 fedora-release is one line. os-release is much more verbose 17:51:55 also much more machine readable 17:51:57 no, I meant /etc/os-release and the /usr/lib/systemd one 17:52:02 oh 17:52:23 $ rpm -qf /etc/os-release 17:52:24 fedora-release-22-0.6.noarch 17:52:30 right. 17:52:35 anyway. 17:52:52 * nirik is sidetracking the discussion based on the "the systemd proposal is for us to make /etc/os-release a symlink pointing into /usr/lib" comment 17:53:00 t8m: I _would_ mildly prefer a way to move this forward to being at least a bit clearer about what is our ISV promise, but +1 cold do. 17:53:46 is there a proposal for how to deal with this ticket? 17:53:50 t8m: +1 17:53:52 Proposal: close ticket with: "FESCo does not see a benefit in deprecating this file at this time." 17:53:59 jwb: t8m proposed close ticket. ;) 17:54:05 oh 17:54:11 (count that as a +1 to close with some wording) 17:54:12 well, yes. but close it with what? 17:54:20 mattdm, +1 17:54:26 sure, mattdm +1 17:54:28 * jwb mumbles something about it already being closed once 17:54:28 mattdm: +1 17:54:43 +1 close 17:54:44 mattdm, +1 17:54:50 jwb, I wanted us to discuss and close on the meeting not outright in the ticket 17:54:52 -1, counterproposal: Ask the ticket submitter to write a man page that documents /etc/fedora-release and suggests /etc/os-release as a cross-distro replacement 17:54:55 and then close the ticket :) 17:55:11 kalev, which will accomplish what? 17:55:28 kalev: in the fedora-release package? man-page dep there might cause some problems... 17:55:36 jwb: It will shorten the cross-distro installation scripts by about 3 lines. 17:55:45 jwb: makes the ticket submitter happy and gives us a new man page with good documentation 17:55:45 how likely is it that people who have written software reading /etc/fedora-release are suddenly going to think "oh, i should read the man page about this file i'm already using" 17:55:47 …scripts targeting F>=2something 17:56:28 jwb: ISTM that argument could be used against introducing any new API at all. 17:56:34 I think a release note has a better chance, but still low 17:56:41 nirik, agreed 17:56:49 jwb: It might still be right but it makes me uneasy. 17:57:19 mitr, possibly so. lennart himself already said in the quoted web page that distros will have to carry their equivalent file until they are ready to break API entirely 17:57:45 I'm not sure there's much advantage to ever removing it... until we change from being Fedora to something else. ;) 17:57:51 exactly 17:58:12 yes, I don't think it can be removed 17:58:23 besides systemd guys there is apparently no agreement which file/interface should be used, so why deprecating anything? 17:58:25 I guess my ideal counterproposal would be something like "bring /usr/bin/lsb_release into the main fedora-release package and document THAT" but I’m not really invested enough in this to bother, so +1 to closing the ticket. 17:58:29 kalev, i'm not -1 to having a man page written, but i don't think that should be fesco's proposed solution. perhaps a #info afterwards 17:58:46 jwb: sure, works for me 17:59:07 ok, so for the record, the info would be: 17:59:08 a readme might be better if you are adding to fedora-release... 17:59:10 jwb: Well if we ask for a man page to be written and don’t decide whether it should say that the file is deprecated, we have essentially delegated the ticket’s decision back to Rahul. 17:59:37 thozza: on the gnome side, we're reading /etc/os-release - its a nice advantage to be able to read a 'neutral' file 17:59:58 mitr, i can't prevent people from writing man pages 18:00:05 how about we say: submitter is encouraged to tell upstreams about the advantages to using /etc/os-release and get projects to use it over old release files? 18:00:23 thinking about it more, i like mattdm's proposal as it stands 18:00:28 jwb: We can prevent people from writing man pages about other people’s packages, I hope. 18:00:31 nirik: sounds very good to me 18:00:54 nirik: This is really targeting cross-distro ISVs and binary distributions though. 18:01:02 mitr: no man pages! info! everyone loves info! :) 18:01:09 mclasen: sure, I;m not saying it is bad to use os-release 18:01:28 oh, in the mean time a comment from fedora's systemd maintainer has appeared in the ticket 18:01:29 mitr, you can't prevent anyone from writing anything. you _can_ prevent it from being packaged though ;) 18:01:34 mitr: well, things we already package I would expect would know what os they are on... but yes, where it makes sense. 18:02:30 and hey, he's going to add the man page. ;) 18:02:52 That man page logically belongs into fedora-release, though, doesn’t it? 18:03:04 I don't think it matters where the man page lives 18:03:07 guys. 18:03:12 as long as it's installed 18:03:12 technicall mattdm's proposal already passed 18:03:19 yep 18:03:22 jwb, +1 18:03:30 unless mattdm wants to retract it, i'm going with exactly what it said 18:03:42 and anything else beyond that is whatever/nice-to-have 18:03:57 * mattdm does not want to retract it 18:03:59 so does anyone want to change their vote? 18:04:01 last chance 18:04:05 no, close it.... 18:04:13 +1, close the ticket 18:05:02 nirik: Hum, your “submitter is encouraged…” would be fine with me actually; cleaning up FOSS software like that can’t hurt. It does nothing for ISVs but that’s not really an objection. 18:05:11 #agreed close ticket with: "FESCo does not see a benefit in deprecating this file at this time." (+1: 7 0:0 -1:0) 18:05:39 i'm not adding an info. you guys can put it in the ticket if you want 18:05:53 OK. 18:06:01 #topic Next week's chair 18:06:32 I probably won't be able to attend next week but I'd take the the chair week after that 18:06:36 I havent done it for a bit. I can do next week 18:06:37 I will not be able to attend next week 18:06:45 ok nirik 18:06:50 * thozza will be at LPC nex week, so won't attend next week 18:06:55 oh 18:06:56 or will we have quorum? 18:07:07 who will be here? i will 18:07:13 I'll be here 18:07:13 * nirik will 18:07:22 * mattdm will 18:07:50 I will. 18:07:53 no idea about dgilmore-afk 18:08:02 cancel next week instead? 18:08:10 I think that dgilmore-afk should be 18:08:17 well, there's 5 that will be here... so thats quorum... 18:08:27 oh, i miscounted nirik 18:08:30 ok 18:08:31 he said that he'll be getting up at 3am in order to meet but is okay with that 18:08:37 #action nirik to chair next week 18:08:41 fun 18:08:47 #topic Open Floor 18:08:55 bring on the open floor 18:09:12 can we do something about adding folks to CC to tickets that are being discussed? 18:09:18 and letting them know when the meeting is? 18:09:28 we can try harder. 18:09:32 Yes, we all can. I can’t see how to automate this though. 18:09:32 aside from adding them to CC and letting them know when the meeting is? 18:09:45 also a few old tickets: https://fedorahosted.org/fesco/ticket/1347 <- anything we need to do here? 18:09:54 we could refuse to discuss tickets that haven't had ample viewing time for involved parties. 18:10:03 because, you know, that would actually make sense 18:10:04 As for the meeting, supposedly the schedule to sent to devel@ should be enough, if it is sent in advance. I hope it is. 18:10:15 it's supposed to be sent a day before. 18:10:20 yes, my mistake 18:10:29 I usually check http://fedoraproject.org/wiki/FESCo_meeting_process to copy the template 18:10:33 but i don't think the day before is sufficient 18:10:35 * nirik also wonders if there's anything we want to discuss on https://fedorahosted.org/fesco/ticket/1353 :) 18:10:59 Therefore, for me at least, adding "invite stakeholders for tickets" to that list would help 18:11:02 nirik, i think we determined that 1347 was done 18:11:12 jwb: Unsure. I hope it is generally understood there is a weekly schedule, but I don’t know how to check. 18:11:14 cool. should close it out then. 18:11:15 unless someone objects i'm going to do that 18:11:51 1347 is at +6, do close it. 18:11:58 done 18:12:03 mattdm: sounds fine to me. 18:12:14 nirik: ooh. and i'll replace the wg status report bit :) 18:12:18 nirik, you opened 1353 but you didn't add meeting to it. so i didn't either 18:12:26 clearly that page is no magic bullet :) 18:12:46 jwb: yeah, sorry. Not sure if it was ready or should have more discussion, etc... I could also punt to list if folks think that would be helpfull. 18:12:55 Is there a way to set up trac to always add that keyword? (Or alternatively, should we switch to a “non-meeting” keyword?) 18:13:02 This keeps happening. 18:13:33 I usually check the 'all active tickets' list and see if there's any that should get meeting added. 18:13:37 nirik, I think this should get wider discussion first, so please send it to devel 18:13:51 nirik, i did that. but i deferred to your lack of meeting keyword 18:13:56 mitr: We could switch to relying on the 'meeting' priority 18:14:02 Then, yes, we can default to it 18:14:03 jwb: just slipped my mind to add. oh well. 18:14:14 nirik, fwiw, i agree with t8m 18:14:17 needs more discussion first 18:14:37 ok, I can post to devel on it. 18:14:44 Well, it seems straightforward: our default package manager can't handle them, ergo do not use them 18:14:51 the "meeting" keyword could be a SOP where we first check the affected people, add them to CC and only then add the meeting kw once eeveryone is listed 18:15:12 kalev, that works 18:15:15 or could work anyway 18:15:31 kalev, +1 18:15:39 kalev: worth trying 18:15:46 I could see that 18:15:47 mattdm, want to add that to the page you're already editing...? 18:15:53 jwb: yes. :) 18:15:56 mattdm: +1 18:16:29 sgallagh: that was my thought... but since they exist peoplle have started using them 18:16:56 But how? 18:17:07 by putting them in the spec files and hoping for the best 18:17:15 I talked with one maintainer and he removed it from f21, but wanted to keep it in rawhide for 'testing' 18:17:32 right. folks using yum and folks using dnf will get different results. 18:17:37 just please don't make it a packaging guideline, it's already way too long -- can we just reject builds using Recommends on the build system side? 18:17:43 * sgallagh just puts his face in his hands 18:17:56 kalev: we could, but then we cant scratch build or the like to test things. 18:18:39 can we make it so non-fesco members can't add the meeting keyword? 18:18:50 I think most maintainers would respond to a simple 'please don't use these yet, thanks 18:18:55 nirik: so test on manually-built repos? Or reject builds depending on the target, but that’s probably overengineering. 18:18:55 mattdm: anyone can 18:19:26 mitr: sure. I guess this would be a redhat-rpm-macros test and fail build if we added it? 18:19:49 nirik: If that can be done, great. 18:19:55 anyhow, I'' post to devel and we can even see if people think this is a problem 18:20:12 proposal: #info Please don't use Recommends yet as our default package manager can't handle them 18:20:34 kalev, I'd like to postpone that after the discussion on devel 18:20:39 nirik: eh. so I'll add a "make sure to double check" to those. 18:20:53 although it most probably will be the outcome 18:20:59 no need to engineer -- if it gets on the agenda and shouldn't have, we can always correct at the meeting itself 18:21:16 mattdm, +1 18:21:31 i have lost all steam 18:22:04 kalev: it's actually any of the 'weak deps'...'Recommends, Suggests, Supplements and Enhances' 18:22:18 ah yes 18:22:42 I'd be +1 to the proposal, but others sound like they want discussion, so lets wait for next week? 18:22:46 sure 18:23:18 proposal #endmeeting 18:23:22 +1 18:23:23 +1 18:23:35 #endmeeting