17:00:07 <jwb> #startmeeting FESCO (2014-10-08)
17:00:07 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:11 <jwb> #meetingname fesco
17:00:11 <zodbot> The meeting name has been set to 'fesco'
17:00:11 <jwb> #chair dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh t8m thozza
17:00:11 <zodbot> Current chairs: dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh t8m thozza
17:00:12 <jwb> #topic init process
17:00:15 <jwb> whee
17:00:18 <thozza> :)
17:00:19 <nirik> morning
17:00:19 <t8m> hi
17:00:21 <thozza> hi
17:00:24 <sgallagh> .hellomynameis sgallagh
17:00:26 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:00:32 * mattdm blinks
17:00:36 <mattdm> .hellomynameis mattdm
17:00:37 <zodbot> mattdm: mattdm 'Matthew Miller' <mattdm@mattdm.org>
17:00:43 <mattdm> how is it 1pm already?
17:00:53 <jwb> no idea, but i'm already exhausted
17:01:08 <mitr> Hello
17:01:52 <mattdm> dilmore is travelling to australia
17:01:52 <jwb> i think we're just waiting for kalev ?
17:02:22 <jwb> let's get rolling
17:02:23 <kalev> hello
17:02:33 <jwb> #topic Consider renaming "Change(s) freeze" and "Beta
17:02:34 <jwb> deadline/accepted changes 100% complete" points
17:02:40 <jwb> .fesco 1351
17:02:41 <jwb> https://fedorahosted.org/fesco/ticket/1351
17:02:43 <zodbot> 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 <jwb> this is a follow up from last week
17:03:03 <jwb> i don't think there's much to really do here other than say good job?
17:03:32 <nirik> yeah.
17:03:38 <nirik> adamw: ^ anything else here ?
17:04:01 <adamw> i still kind of liked the numbered checkpoints (mumble mumble) but no, i think it's fine
17:04:06 <adamw> oh
17:04:15 <adamw> there is the stuff at the end of my last comment about what exactly these points *mean*
17:04:47 <adamw> "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 <jwb> i'd say the latter
17:05:39 * nirik nods
17:05:47 <t8m> It should be the latter
17:05:49 <adamw> 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 <sgallagh> yes, the latter
17:05:56 <thozza> I agree that the second sound more reasonable.
17:06:01 <t8m> the question is whether it is actually but...
17:06:05 <thozza> better than doing all the checking at once
17:06:12 <adamw> i'll see if i can do a light edit which brings that out a bit more clearly
17:06:23 <jwb> ok
17:06:30 <adamw> 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 <jwb> "fesco looks at them" is enough for your changes for now
17:07:10 <mattdm> I agree with jwb
17:07:38 <jwb> 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 <adamw> 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 <jwb> yep
17:07:57 <adamw> nobody expects the fesco inquisition!
17:08:00 <adamw> gotcha
17:08:23 <jwb> anything else before we move on?
17:08:46 <t8m> LOL
17:08:50 * jreznik is reading
17:08:55 <adamw> i think it's ok for me
17:08:57 <nirik> ha.
17:09:13 <adamw> 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 <kalev> adamw: it's totally awesome you're doing the wiki editing, by the way
17:09:26 <kalev> much needed cleanup
17:09:31 <jwb> agreed
17:09:56 <sgallagh> #info FESCo pats adamw on the back. Attaboy!
17:10:02 * jwb looks at jreznik before moving on...
17:10:04 <jreznik> kalev: definitely! it was amazing job
17:10:18 <jreznik> for the time when it's checked by fesco
17:10:21 <nirik> quite. :) thanks!
17:10:43 <jreznik> usually, deadline is on tuesday, I send it to fesco for the first review next day (for this meeting)
17:11:15 <jwb> right
17:11:37 <mattdm> jreznik: details details :)
17:11:41 <jwb> ok, next topic
17:11:43 <jwb> #topic FPC is not working
17:11:43 <jwb> .fesco 1346
17:11:44 <jwb> https://fedorahosted.org/fesco/ticket/1346
17:11:44 <zodbot> jwb: #1346 (FPC is not working) – FESCo - https://fedorahosted.org/fesco/ticket/1346
17:11:57 <mitr> I apologize for only adding comments after this meeting started.
17:12:28 <mitr> 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 <mattdm> yes I was just going to note that I hadn't read all of those :)
17:12:59 <mattdm> mitr: and status quo until that point?
17:13:01 <nirik> mitr: I can definitely see where you are coming from there... ;)
17:13:27 <jwb> so i'm kind of angry with this ticket
17:13:27 <mitr> mattdm: With the assumption that the hard thinking would take no more than a month, yes.
17:14:01 <jwb> 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 <jwb> i really dislike this trend
17:15:04 <t8m> ok we could say that this was a mistake, but does that make the ticket invalid?
17:15:12 <jwb> in my opinion, yes
17:15:20 <jwb> it's exactly the opposite of how fedora should be operating
17:15:26 <jwb> fesco doesn't solve things top down
17:15:40 <jwb> and there was no discussion with the ACTUAL GROUP BEING DISCUSSED
17:16:49 <nirik> I agree that was bad.
17:17:10 <jwb> even if we ignore that entire aspect, what is fesco supposedly going to do here?
17:17:44 <jwb> rip up the FPC and replace it with... what?  because i know fesco doesn't want to do that.
17:17:45 <t8m> there are concrete proposals which we could approve or reject
17:17:51 <jwb> no, there aren't
17:17:57 <mitr> 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 <t8m> yes they are
17:18:08 <t8m> mitr, +1
17:18:10 <jwb> there are proposals made by fesco members that have had NO discussion with the people they impact
17:18:21 <nirik> s/non fesco members/
17:18:30 <mitr> They are still proposals.
17:18:43 <jwb> this is absurd
17:18:49 <jreznik> 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 <mitr> jwb: Don’t forget this also impacts the ≥1000 other packagers.
17:18:56 <jwb> you want to approve something that only fesco has discussed?
17:19:05 <jwb> and force work on people without even talking to them?
17:19:25 <mitr> jwb: I really don’t think we were at the point of approving anything today.
17:19:32 <t8m> where we are saying that we want to approve things just now????
17:19:43 <jwb> why are proposals being made then?
17:19:52 <t8m> using words as absurd etc. does not get us anywhere anyway
17:20:19 <jwb> 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 <jwb> why are we discussing this?
17:20:32 <thozza> we could agree to finally discuss this with FPC and WGs
17:20:36 <thozza> *first
17:20:39 <jwb> that's backwards
17:20:39 <mitr> 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 <mitr> 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 <kalev> I think originally FPC was just one person -- the fesco at that time appointed spot to take care of packaging guidelines
17:20:58 <t8m> we are discussing what we could ask the people which proposed the things to do
17:21:01 <kalev> and he grew the fpc around him to help wit hthe task
17:21:07 <kalev> at least that's what I've heard, I wasn't involved with Fedora back then :)
17:21:17 <t8m> kalev, I think you're basically right
17:21:17 <spot> kalev: that's accurate.
17:21:19 <kalev> 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 <mitr> jwb: And I think Workstation was asking for this as well.
17:21:23 <kalev> and then fesco would give them the authority to do that
17:21:30 <nirik> how about we open a discussion about pain points and possible help on the packaging list?
17:21:33 <jwb> mitr, um... no
17:21:41 <jwb> the Workstation WG has not discussed this
17:21:50 <jreznik> 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 <mitr> nirik: s/packaging/devel/
17:22:11 <t8m> IMHO the topic was really badly chosen but that does not invalidate the ticket completely
17:22:21 <nirik> 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 <nirik> mitr: I suppose... packaging is where the FPC folks all hang out, but devel would be ok with me too.
17:23:03 <kalev> 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 <mitr> nirik: packaging is where most of the others don’t hang out I think.
17:23:24 <jreznik> 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 <t8m> kalev, +1
17:23:42 <jwb> wait
17:23:50 <jwb> why are we now asking the FPL to go solve this?
17:23:50 <nirik> also, Note: FPC has added one new member already at the last meeting.
17:24:06 <jwb> you guys are really blowing my mind here
17:24:21 <mattdm> proposal: close ticket, find someone to facilitate meetings between current FPC and other stakeholders (Env & Stacks, Base WG, others?)
17:24:29 <jwb> stop pushing things up the stack and start having broad discussions as jreznik and nirik have suggested
17:24:29 <t8m> mattdm, -1
17:24:35 <jwb> mattdm, +1
17:25:04 <mitr> 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 <jreznik> mattdm: if agreed on, I'll take care of it
17:25:13 <nirik> 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 <mattdm> kalev: I'm not sure that it's a one person kind of job
17:25:19 <t8m> nirik, +1
17:26:23 <mattdm> 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 <jwb> sounds like "facilitator"
17:27:24 <nirik> ok, so someone to post to devel? or you mean something above that?
17:27:56 <mattdm> nirik: I think both post to devel and help make sure that there's followup
17:28:15 <jreznik> mattdm: yep
17:28:16 <nirik> alright. fine with me if someone wants to do that. ;)
17:28:18 <jwb> shephard, liasion, moderator, facilitator, host, etc.  pick a word
17:28:37 <mattdm> jreznik just to be clear it sounds like you're volunteering, right? :)
17:29:00 <t8m> 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 <mattdm> 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 <mitr> mattdm: Yeah.
17:30:24 <jwb> jreznik had the proposal.  he seems apt to lead the discussion
17:30:26 <nirik> 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 <jreznik> mattdm: I can, at leat help
17:30:46 <mattdm> jreznik: yes not going to leave you _alone_ to hang :)
17:31:08 <t8m> nirik, I think that splitting the parts of the guidelines that affect only particular groups to them is another good thing
17:31:32 <nirik> what might help for posts would be to take a postive tone... "How to improve packaging and FPC" , etc
17:31:32 <jreznik> nirik: interested/expert - that's the main part of all discussion and it's definitely not easy at all
17:31:33 <mattdm> let's not try to come up with a solution in this vacuum here though
17:31:33 <mitr> 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 <nirik> t8m: I am strongly against that for packages in the main collection.
17:31:59 <mattdm> since we already agreed that we're in an (albeit unintentional) vacuum of the people who need to be included.
17:32:19 <nirik> I'm perfectly fine with something like the playground group having different guidelines set by the stacks and env group tho
17:32:26 <jwb> nirik, t8m, mitr: we aren't solving the guidelines in this meeting.
17:32:36 <jwb> move that discussion to the lists
17:32:38 * nirik stops, waits for disucssion on list.
17:32:46 <mitr> OK.  So, proposal: jreznik to open discussion on devel@ ?
17:32:51 <mattdm> +1
17:32:52 <jwb> yes, +1
17:32:53 <t8m> 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 <nirik> +1
17:32:57 <mitr> +1 for the record
17:32:58 <t8m> but nevertheless
17:33:06 <kalev> +1
17:33:07 <thozza> mitr: +1
17:33:09 <t8m> +1 to that
17:33:16 <mitr> t8m: because “do not really affect anything else" is very rarely true.
17:33:17 <kalev> 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 <nirik> t8m: they are trying to figure the best and most maintainable way to sustainably package things...
17:33:53 <mattdm> okay okay okay y'all :)
17:33:55 <jwb> #agreed jreznik to open discussion on devel@ (+1: 7 0:0 -1:0)
17:34:05 <jwb> #action jreznik to open discussion on devel@
17:34:07 <jwb> moving on.
17:34:13 <jwb> #topic Bash scripts should rely on bash explicitly
17:34:13 <jwb> .fesco 1352
17:34:14 <jwb> https://fedorahosted.org/fesco/ticket/1352
17:34:15 <zodbot> jwb: #1352 (Bash scripts should rely on bash explicitly) – FESCo - https://fedorahosted.org/fesco/ticket/1352
17:34:15 <jreznik> adding to my todo's for tomorrow
17:34:55 <jwb> so this ticket is expliction not about switching shells
17:34:56 <jwb> which helps
17:34:57 <t8m> I basically agree with what mitr said in the ticket
17:35:11 <jwb> i tend to agree with mitr as well
17:35:13 <sgallagh> 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 <mattdm> I am +1 to nirik's -1
17:36:13 <jwb> could simply send an email asking them to review.  it would be a token effort at best
17:36:28 <thozza> 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 <sgallagh> Proposal: Ask Rahul to socialize the intended interpreter change instead of trying to make it policy.
17:36:52 <jwb> socialize?
17:37:03 <kalev> 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 <mitr> 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 <kalev> 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 <mitr> 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 <jwb> mitr, which is why an easily ignored email seems fine?
17:37:50 <sgallagh> "socialize" as in make a case in upstreams for doing this
17:37:53 <nirik> 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 <jwb> sgallagh, i'd rather just say "push this discussion upstream"
17:38:07 <mitr> sgallagh: "make a case in upstreams", sure.
17:38:11 <mattdm> 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 <sgallagh> mitr: Honestly, I can't see that it's worth the effort spent automating it
17:38:28 <sgallagh> jwb: Fine by me
17:38:32 <jwb> mattdm, right.  they can go do that all they want
17:38:35 <mitr> sgallagh: I’d expect it to be comparable with automating sending the emails :)
17:38:46 <t8m> 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 <kalev> mattdm: I'd rather not have downstream patches carried by the distro just to change the interpreter.
17:39:02 <mitr> 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 <t8m> kalev, +1
17:39:24 <mattdm> kalev: true
17:39:26 <jwb> mitr, that sounds like an entirely different problem
17:39:33 <sgallagh> 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 <jwb> so is the proposal to ask rahul to work with upstreams on this?
17:39:58 <mitr> sgallagh: I have conveniently completely forgotten who it was ;-)
17:40:19 <kalev> jwb: yes, that would be my suggestion
17:40:24 <nirik> jwb: I'd be fine with that.
17:40:25 <sgallagh> jwb: That sounds like a reasonable rephrasing
17:40:30 <mitr> +1 to that.
17:40:33 <t8m> jwb, +1
17:40:37 <kalev> +1
17:40:45 <sgallagh> 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 <jwb> +1
17:41:01 <thozza> +1
17:41:03 <kalev> +1
17:41:19 <nirik> +1
17:41:23 <sgallagh> +1
17:41:23 <jwb> mattdm, ?
17:41:30 <mattdm> +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 <mattdm> sorry writing long thing :)
17:41:53 <mattdm> that's okay in fedora wiki or somewhere
17:42:14 <mitr> mattdm: Sure.
17:42:18 <t8m> sure
17:42:26 <jwb> #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 <jwb> #info a list of packages with checkbashisms failures can be kept outside of bugzilla to facilitate the upstream effort
17:42:59 <mattdm> so what about about cases where the problem is in our patches or added scripts?
17:43:13 <kalev> then we're the upstream and it makes sense to file tickets in rhbz
17:43:21 <jwb> yeah, that seems like a common sense bug
17:43:31 <jwb> do we need to codify common sense?
17:43:38 <mattdm> jwb: sometimes?
17:43:51 <jwb> because the only thing about common sense is how it isn't common?
17:43:55 <mitr> 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 <nirik> jwb: thats such a common saying. ;)
17:44:05 <mattdm> #info if fedora packages are the upstream, it's okay to file bugs
17:44:13 <mattdm> okay I'm done :)
17:44:26 <t8m> i do not really think it makes much sense there either without actually finding someone to fix these "bugs"
17:44:42 <jwb> it can't hurt
17:44:48 <jwb> worst case, the bug is ignored
17:44:54 <jwb> best case, the maintainer fixes it
17:45:00 <jwb> and the bugs should be relatively low in number
17:45:15 <jwb> moving on
17:45:23 <jwb> #topic deprecate fedora-release file
17:45:24 <jwb> .fesco 1354
17:45:24 <jwb> https://fedorahosted.org/fesco/ticket/1354
17:45:25 <zodbot> 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 <jwb> neither of the people that should be taking to each other about this are present today
17:45:58 <kalev> 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 <kalev> apparently it's no longer /etc/fedora-release
17:46:18 <mattdm> 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 <thozza> I think the man page is a good idea
17:46:21 <kalev> but I've no idea how to add the documentation, beyond adding man pages
17:46:36 <thozza> also to explain what should be used (preferably)
17:46:41 <kalev> thozza: +1
17:46:49 <nirik> 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 <t8m> kalev, thozza , +1
17:47:07 <mattdm> 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 <nirik> but there's 0 reason to override the maintainer and make this depreciated now before the new one is popular/used.
17:47:14 <mattdm> which we still do ship
17:47:32 <mitr> kalev: AFAICT /etc/fedora-release works perfectly fine.  Or doesn’t it?
17:47:46 <nirik> mitr: it does.
17:47:48 <jwb> kalev, i don't think that's apparent
17:47:52 <nirik> redhat-release is a link
17:47:54 <mattdm> 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 <kalev> mitr: its downside is that it's a fedora only file
17:48:01 <nirik> anyhow, no point here. save 4k?
17:48:02 <mattdm> Which we are a million years (give or take) from doing
17:48:05 <jwb> i think it's apparent that systemd invented a new file format and it could be used
17:48:05 <randomuser> is this about /usr/lib/os-release and the associated symlink, from upstream systemd?
17:48:31 <mitr> 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 <nirik> randomuser: no
17:48:38 <nirik> it's about our /etc/os-release
17:48:51 * randomuser nods, will read more background
17:49:12 <thozza> I think this ticket tries to solve a problem that didn't happen yet
17:49:17 <mattdm> nirik: the systemd proposal is for us to make /etc/os-release a symlink pointing into /usr/lib
17:49:23 <mattdm> because os release is not really configuration
17:49:24 <jwb> thozza, yes.  in a poor manner
17:49:28 <mattdm> thozza++++++++++++++++++++++++
17:49:37 <nirik> mattdm: where is that?
17:49:51 <mattdm> nirik: lennart mentioned it on devel list, I think?
17:49:53 <t8m> 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 <mitr> 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 <mattdm> nirik: yes. this one obviously needs coordination
17:50:44 <mitr> As if that symlink made things clearer…
17:50:49 <kalev> 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 <jwb> 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 <jwb> http://0pointer.de/blog/projects/os-release.html
17:51:19 <mitr> 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 <nirik> anyhow, if the contents are the same and it's coordinated with fedora-release thats fine.
17:51:34 <jwb> they aren't the same
17:51:44 <jwb> fedora-release is one line.  os-release is much more verbose
17:51:55 <mclasen> also much more machine readable
17:51:57 <nirik> no, I meant /etc/os-release and the /usr/lib/systemd one
17:52:02 <jwb> oh
17:52:23 <mattdm> $ rpm -qf /etc/os-release
17:52:24 <mattdm> fedora-release-22-0.6.noarch
17:52:30 <nirik> right.
17:52:35 <mattdm> 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 <mitr> 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 <jwb> is there a proposal for how to deal with this ticket?
17:53:50 <nirik> t8m: +1
17:53:52 <mattdm> Proposal: close ticket with: "FESCo does not see a benefit in deprecating this file at this time."
17:53:59 <nirik> jwb: t8m proposed close ticket. ;)
17:54:05 <jwb> oh
17:54:11 <mattdm> (count that as a +1 to close with some wording)
17:54:12 <jwb> well, yes.  but close it with what?
17:54:20 <t8m> mattdm, +1
17:54:26 <nirik> sure, mattdm +1
17:54:28 * jwb mumbles something about it already being closed once
17:54:28 <thozza> mattdm: +1
17:54:43 <sgallagh> +1 close
17:54:44 <jwb> mattdm, +1
17:54:50 <t8m> jwb, I wanted us to discuss and close on the meeting not outright in the ticket
17:54:52 <kalev> -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 <kalev> and then close the ticket :)
17:55:11 <jwb> kalev, which will accomplish what?
17:55:28 <nirik> kalev: in the fedora-release package? man-page dep there might cause some problems...
17:55:36 <mitr> jwb: It will shorten the cross-distro installation scripts by about 3 lines.
17:55:45 <kalev> jwb: makes the ticket submitter happy and gives us a new man page with good documentation
17:55:45 <jwb> 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 <mitr> …scripts targeting F>=2something
17:56:28 <mitr> jwb: ISTM that argument could be used against introducing any new API at all.
17:56:34 <nirik> I think a release note has a better chance, but still low
17:56:41 <jwb> nirik, agreed
17:56:49 <mitr> jwb: It might still be right but it makes me uneasy.
17:57:19 <jwb> 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 <nirik> I'm not sure there's much advantage to ever removing it... until we change from being Fedora to something else. ;)
17:57:51 <jwb> exactly
17:58:12 <kalev> yes, I don't think it can be removed
17:58:23 <thozza> besides systemd guys there is apparently no agreement which file/interface should be used, so why deprecating anything?
17:58:25 <mitr> 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 <jwb> 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 <kalev> jwb: sure, works for me
17:59:07 <jwb> ok, so for the record, the info would be:
17:59:08 <nirik> a readme might be better if you are adding to fedora-release...
17:59:10 <mitr> 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 <mclasen> 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 <jwb> mitr, i can't prevent people from writing man pages
18:00:05 <nirik> 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 <jwb> thinking about it more, i like mattdm's proposal as it stands
18:00:28 <mitr> jwb: We can prevent people from writing man pages about other people’s packages, I hope.
18:00:31 <kalev> nirik: sounds very good to me
18:00:54 <mitr> nirik: This is really targeting cross-distro ISVs and binary distributions though.
18:01:02 <nirik> mitr: no man pages! info! everyone loves info! :)
18:01:09 <thozza> mclasen: sure, I;m not saying it is bad to use os-release
18:01:28 <kalev> oh, in the mean time a comment from fedora's systemd maintainer has appeared in the ticket
18:01:29 <jwb> mitr, you can't prevent anyone from writing anything.  you _can_ prevent it from being packaged though ;)
18:01:34 <nirik> 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 <nirik> and hey, he's going to add the man page. ;)
18:02:52 <mitr> That man page logically belongs into fedora-release, though, doesn’t it?
18:03:04 <kalev> I don't think it matters where the man page lives
18:03:07 <jwb> guys.
18:03:12 <kalev> as long as it's installed
18:03:12 <jwb> technicall mattdm's proposal already passed
18:03:19 <nirik> yep
18:03:22 <t8m> jwb, +1
18:03:30 <jwb> unless mattdm wants to retract it, i'm going with exactly what it said
18:03:42 <jwb> and anything else beyond that is whatever/nice-to-have
18:03:57 * mattdm does not want to retract it
18:03:59 <jwb> so does anyone want to change their vote?
18:04:01 <jwb> last chance
18:04:05 <thozza> no, close it....
18:04:13 <kalev> +1, close the ticket
18:05:02 <mitr> 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 <jwb> #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 <jwb> i'm not adding an info.  you guys can put it in the ticket if you want
18:05:53 <mitr> OK.
18:06:01 <jwb> #topic Next week's chair
18:06:32 <t8m> I probably won't be able to attend next week but I'd take the the chair week after that
18:06:36 <nirik> I havent done it for a bit. I can do next week
18:06:37 <sgallagh> I will not be able to attend next week
18:06:45 <jwb> ok nirik
18:06:50 * thozza will be at LPC nex week, so won't attend next week
18:06:55 <jwb> oh
18:06:56 <nirik> or will we have quorum?
18:07:07 <jwb> who will be here?  i will
18:07:13 <kalev> I'll be here
18:07:13 * nirik will
18:07:22 * mattdm will
18:07:50 <mitr> I will.
18:07:53 <jwb> no idea about dgilmore-afk
18:08:02 <jwb> cancel next week instead?
18:08:10 <mattdm> I think that dgilmore-afk should be
18:08:17 <nirik> well, there's 5 that will be here... so thats quorum...
18:08:27 <jwb> oh, i miscounted nirik
18:08:30 <jwb> ok
18:08:31 <mattdm> he said that he'll be getting up at 3am in order to meet but is okay with that
18:08:37 <jwb> #action nirik to chair next week
18:08:41 <nirik> fun
18:08:47 <jwb> #topic Open Floor
18:08:55 <jwb> bring on the open floor
18:09:12 <kalev> can we do something about adding folks to CC to tickets that are being discussed?
18:09:18 <kalev> and letting them know when the meeting is?
18:09:28 <nirik> we can try harder.
18:09:32 <mitr> Yes, we all can.  I can’t see how to automate this though.
18:09:32 <jwb> aside from adding them to CC and letting them know when the meeting is?
18:09:45 <nirik> also a few old tickets: https://fedorahosted.org/fesco/ticket/1347 <- anything we need to do here?
18:09:54 <jwb> we could refuse to discuss tickets that haven't had ample viewing time for involved parties.
18:10:03 <jwb> because, you know, that would actually make sense
18:10:04 <mitr> 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 <nirik> it's supposed to be sent a day before.
18:10:20 <jwb> yes, my mistake
18:10:29 <mattdm> I usually check http://fedoraproject.org/wiki/FESCo_meeting_process to copy the template
18:10:33 <jwb> 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 <mattdm> Therefore, for me at least, adding "invite stakeholders for tickets" to that list would help
18:11:02 <jwb> nirik, i think we determined that 1347 was done
18:11:12 <mitr> jwb: Unsure.  I hope it is generally understood there is a weekly schedule, but I don’t know how to check.
18:11:14 <nirik> cool. should close it out then.
18:11:15 <mattdm> unless someone objects i'm going to do that
18:11:51 <mitr> 1347 is at +6, do close it.
18:11:58 <jwb> done
18:12:03 <nirik> mattdm: sounds fine to me.
18:12:14 <mattdm> nirik: ooh. and i'll replace the wg status report bit :)
18:12:18 <jwb> nirik, you opened 1353 but you didn't add meeting to it.  so i didn't either
18:12:26 <mattdm> clearly that page is no magic bullet :)
18:12:46 <nirik> 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 <mitr> 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 <mitr> This keeps happening.
18:13:33 <nirik> I usually check the 'all active tickets' list and see if there's any that should get meeting added.
18:13:37 <t8m> nirik, I think this should get wider discussion first, so please send it to devel
18:13:51 <jwb> nirik, i did that.  but i deferred to your lack of meeting keyword
18:13:56 <sgallagh> mitr: We could switch to relying on the 'meeting' priority
18:14:02 <sgallagh> Then, yes, we can default to it
18:14:03 <nirik> jwb: just slipped my mind to add. oh well.
18:14:14 <jwb> nirik, fwiw, i agree with t8m
18:14:17 <jwb> needs more discussion first
18:14:37 <nirik> ok, I can post to devel on it.
18:14:44 <sgallagh> Well, it seems straightforward: our default package manager can't handle them, ergo do not use them
18:14:51 <kalev> 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 <jwb> kalev, that works
18:15:15 <jwb> or could work anyway
18:15:31 <t8m> kalev, +1
18:15:39 <mattdm> kalev: worth trying
18:15:46 <sgallagh> I could see that
18:15:47 <jwb> mattdm, want to add that to the page you're already editing...?
18:15:53 <mattdm> jwb: yes. :)
18:15:56 <mitr> mattdm: +1
18:16:29 <nirik> sgallagh: that was my thought... but since they exist peoplle have started using them
18:16:56 <sgallagh> But how?
18:17:07 <jwb> by putting them in the spec files and hoping for the best
18:17:15 <nirik> I talked with one maintainer and he removed it from f21, but wanted to keep it in rawhide for 'testing'
18:17:32 <nirik> right. folks using yum and folks using dnf will get different results.
18:17:37 <kalev> 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 <nirik> kalev: we could, but then we cant scratch build or the like to test things.
18:18:39 <mattdm> can we make it so non-fesco members can't add the meeting keyword?
18:18:50 <nirik> I think most maintainers would respond to a simple 'please don't use these yet, thanks
18:18:55 <mitr> nirik: so test on manually-built repos?  Or reject builds depending on the target, but that’s probably overengineering.
18:18:55 <nirik> mattdm: anyone can
18:19:26 <nirik> mitr: sure. I guess this would be a redhat-rpm-macros test and fail build if we added it?
18:19:49 <mitr> nirik: If that can be done, great.
18:19:55 <nirik> anyhow, I'' post to devel and we can even see if people think this is a problem
18:20:12 <kalev> proposal: #info Please don't use Recommends yet as our default package manager can't handle them
18:20:34 <t8m> kalev, I'd like to postpone that after the discussion on devel
18:20:39 <mattdm> nirik: eh. so I'll add a "make sure to double check" to those.
18:20:53 <t8m> although it most probably will be the outcome
18:20:59 <mattdm> 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 <t8m> mattdm, +1
18:21:31 <jwb> i have lost all steam
18:22:04 <nirik> kalev: it's actually any of the 'weak deps'...'Recommends, Suggests, Supplements and Enhances'
18:22:18 <kalev> ah yes
18:22:42 <nirik> I'd be +1 to the proposal, but others sound like they want discussion, so lets wait for next week?
18:22:46 <kalev> sure
18:23:18 <mattdm> proposal #endmeeting
18:23:22 <t8m> +1
18:23:23 <kalev> +1
18:23:35 <jwb> #endmeeting