17:02:46 <spot> #startmeeting Fedora Packaging Committee
17:02:46 <zodbot> Meeting started Wed Feb  6 17:02:46 2013 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:02:49 <spot> #meetingname fpc
17:02:49 <zodbot> The meeting name has been set to 'fpc'
17:02:57 <spot> #topic Roll Call
17:03:08 <spot> I see limburgher, geppetto, racor, tibbs, abadger1999
17:03:19 <abadger1999> greetings
17:03:23 * SmootherFrOgZ is around
17:03:25 <racor> here
17:03:37 <spot> rdieter: ping?
17:03:59 <sochotni> me as well even if I am not directly responsible for anything I have two tickets in queue :-)
17:04:10 <spot> sochotni: 251 and?
17:04:17 <sochotni> 252 I believe
17:04:20 <sochotni> though that's low prio
17:04:29 <sochotni> yeah, 252
17:04:43 * SmootherFrOgZ sees only 4 items for today meeting. do you have more?
17:05:04 <spot> okay, we have more than quorum
17:05:09 * limburgher contrasts FPC agenda with FESCO agenda for today
17:05:13 <tibbs> Someone was pinging me about some old tickets earlier in the week.
17:05:18 * limburgher feels pretty good right about now
17:05:22 <spot> #topic Change BR: maven to BR: maven-local - https://fedorahosted.org/fpc/ticket/251
17:05:41 <spot> sochotni: does maven-local exist in F16, F17, F18 ?
17:06:07 * rdieter is 1/2 here , 1/2 occupied @work stuff
17:06:30 <sochotni> spot: just today I've backported package to F17+
17:06:40 <sochotni> I skipped F16
17:06:48 <tibbs> If it's not in F16, we should probably wait until F16 does EOL.
17:06:50 <mizdebsk> spot: it exists in all fedoras f16+
17:06:56 <rdieter> would be nice if that wasn't conditional on f19+
17:06:59 <spot> sochotni: i assume EPEL (EL4, EL5, EL6) does not have it though
17:07:09 <mizdebsk> spot: there is no maven in epel
17:07:11 <sochotni> spot: EL doesn't have maven at all
17:07:15 <spot> easy enough.
17:07:38 <sochotni> I have arranged things with dgilmore so there should be no surprises
17:07:50 <limburgher> In that case this looks pretty painless.
17:09:05 <spot> Fedora 16 EOL is Feb 12.
17:09:22 <spot> so I think the window of possible pain is very small. I'm fine with making this change now
17:09:23 <tibbs> Meh, probably not worth holding things up.
17:09:25 <sochotni> that was reason why I didn't bother with it
17:09:28 <mizdebsk> spot: maven-local is in F16 too
17:09:30 <spot> +1 to this change
17:09:34 <limburgher> +1 also.
17:09:34 <tibbs> +1
17:09:46 <SmootherFrOgZ> +1 from me
17:09:53 <abadger1999> +1
17:10:05 <geppetto> +1
17:10:19 <sochotni> mizdebsk: right, forgotten that it's provided by different package there
17:10:27 <sochotni> but anyway it doesn't matter much :-)
17:10:34 <spot> racor, rdieter, if you'd like to vote on the record.
17:10:42 <rdieter> +1
17:10:44 <racor> +1
17:10:50 <spot> #action Approved (+1:8, 0:0, -1:0)
17:11:00 <sochotni> thanks, we'll get down to it then
17:11:30 <spot> #topic Drop Fedora Vendor tag from Desktop files in F19+ - https://fedorahosted.org/fpc/ticket/247
17:11:52 <tibbs> Seems people are just doing this anyway and not caring about the breakage.
17:11:57 <spot> I'd like to start off by saying that I hate the vendor tag in the desktop files with a burning passion.
17:12:05 <rdieter> tibbs: doing it on fedora != 19 ?
17:12:05 <tibbs> It should never have been allowed.
17:12:32 <spot> I think if we conditionalize it %if 0%{?fedora} > 18
17:12:36 <tibbs> rdieter: I don't see how the release matters.
17:12:49 <tibbs> Guidelines say you cannot change it once you've used it.
17:12:54 <spot> then we'll have a one time hit of pain for the people who use tools that make assumptions
17:12:57 <rdieter> tibbs: our current guidelines say on existing releases don't modify vendor, else kill it!
17:13:13 <abadger1999> +1 for one time hit of pain.
17:13:20 <tibbs> rdieter: Untrue.
17:13:26 <tibbs> Guidelines say "for the life of the package".
17:13:36 <rdieter> the life of the package *on that release*, no?
17:13:43 <tibbs> No.
17:13:56 <tibbs> http://fedoraproject.org/wiki/Packaging:Guidelines#desktop-file-install_usage
17:13:58 * abadger1999 agrees with tibbs about the current interpretation of the guideline
17:14:00 <rdieter> that was the intent at least (I wrote it), but maybe that verbiage ended up getting removed
17:14:20 <rdieter> sigh
17:14:21 <spot> I propose that we amend the guidelines to say that for Fedora 19 and beyond, the vendor tag must not be used. If it was being used in a previous release, it may continue to be used for that previous release, but must be removed in Fedora 19. New packages must not add the vendor tag for any release.
17:14:28 <rdieter> spot: +1
17:14:41 <limburgher> +1
17:14:42 <tibbs> +1
17:14:43 <abadger1999> spot: +1
17:14:45 <spot> +1
17:14:46 <SmootherFrOgZ> +1
17:14:51 <tibbs> At this point it's more annoying than the breakage.
17:14:57 <limburgher> Any idea how wide a swath this cuts?
17:15:07 <tibbs> There was a repoquery that will show you.
17:15:10 <spot> limburgher: i believe that is FESCo's problem. ;)
17:15:13 <limburgher> I saw that.
17:15:27 <limburgher> spot: :)
17:15:36 <spot> (which means that two weeks before beta, i'll be committing the changes frantically, but i digress)
17:15:44 <racor> +1
17:16:00 <spot> geppetto: want to vote on the record?
17:16:05 <limburgher> spot:  Feel free to shoot me an email with part of a list if you want extra PP hands.
17:16:11 <geppetto> meh. … sorry was looking away.
17:16:11 <rdieter> I vaguely recall someone throwing around some large number in the hundreds, but I don't see that in the ticket
17:16:25 <tibbs> The piecemeal breakage over the years as people ignored this guideline has been pretty annoying, though.
17:16:26 <geppetto> Was going to ask … is it possible to ship both .desktop files for a release?
17:16:31 <geppetto> Or does that screw thing up?
17:16:38 <tibbs> I do an update and someone complains that some icon of theirs disappeared.
17:16:43 <spot> geppetto: that is actually worse.
17:16:49 <tibbs> geppetto: You get doubled entries in various menus.
17:16:53 <geppetto> fair enough … +1
17:17:00 <spot> #action spot's proposal approved (+1:8, 0:0, -1:0)
17:18:03 <racor> rdieter: the number is hidden in a link contained in comment 4 in trac http://lists.fedoraproject.org/pipermail/packaging/2013-January/008880.html
17:18:10 <spot> #topic NodeJS reopened - https://fedorahosted.org/fpc/ticket/246
17:18:23 <racor> mentions 618 packages
17:18:30 <rdieter> eep
17:18:36 <rdieter> that's a lot alright
17:18:42 <spot> Honestly, with all respect to vondruch, I don't think this merits being revisited. If he (or anyone) wants to propose separate javascript guidelines, they can.
17:19:14 <tibbs> I'm not sure I understand his objection.
17:19:16 <spot> the files calling #!/usr/bin/node are almost certainly assuming node, not "any javascript runtime"
17:19:44 <spot> so, I propose we reclose the bug.
17:19:55 * rdieter doesn't understand what the problem is either
17:20:01 <abadger1999> So, sgallagh mentioned to me at fudcon that almost any JS could be easily adapted to be a nodejs package.
17:20:09 <abadger1999> But I'm not sure that addresses vondruch's concern.
17:20:13 <tibbs> Is his complaint simply that there are some javascript-related packages which are not covered by the guideline?
17:20:15 <limburgher> Sounds reasonable.  A new one can be opened for js guidelines, be it the mentioned draft or another.
17:20:16 <spot> abadger1999: i think thats the opposite.
17:20:25 <rdieter> tibbs: maybe? :)
17:20:28 <tibbs> Because I didn't think it was supposed to cover all of javascript.
17:20:33 <abadger1999> If it doesn't, then I'd have to say the package he's talking about is bundling and shouldn't have been approved
17:20:43 <spot> it pretty clearly is not intended to cover anything besides node modules
17:20:49 <spot> or whatever they call themselves.
17:21:08 <abadger1999> spot: well -- coffeescript is listed on the nodejs registry web page thingy.
17:21:34 <spot> abadger1999: yes, but just because something can work with node is different from requiring node
17:22:03 <spot> is anyone opposed to closing #246?
17:22:43 <abadger1999> +1 close.  Someone needs to make a draft for server-side js that is not nodejs.
17:22:46 <tibbs> I guess he can clarify his argument and reopen the ticket if he wants.
17:22:48 <spot> i hear no objections.
17:23:00 <abadger1999> failing that, non-nodejs server side js should be blocked on guidelines.
17:23:30 * SmootherFrOgZ is not
17:24:05 <spot> #topic Consider a ban on SysVinit scripts - https://fedorahosted.org/fpc/ticket/243
17:24:24 <spot> When we did systemd the first time, there were still packaged and maintained alternatives that used sysvinit
17:24:33 <spot> Hence, the subpackage exception
17:24:47 <spot> However, since then, I do not believe there are any maintained alternatives
17:25:07 <tibbs> I don't really see the harm in these things
17:25:38 <spot> (well, okay, sysv is still maintained, but i don't want to believe anyone is that masochistic)
17:25:54 <limburgher> I'm with tibbs.
17:25:58 <geppetto> On the other side, I don't see the harm in banning sysv scripts in fedora
17:26:17 <spot> I think the compromise proposal is that they can be packaged as %doc (and chmod -x)
17:26:48 <spot> if someone really wants to use it, it is easy enough for them to copy it into the systemd /etc hierarchy and override the unit file.
17:26:56 <abadger1999> sysvinit has:
17:26:59 <abadger1999> %if 0
17:27:01 <abadger1999> # Disabled for upstart.
17:27:02 <abadger1999> %files
17:27:05 <abadger1999> [...]
17:27:31 <tibbs> Usually when we get some kind of "Ban it!" request I have to ask if there's something else going on.
17:27:33 <rdieter> spot: +1 (I'm ok without compromise too, for what it's worth)
17:27:38 <spot> abadger1999: so, basically, there are no-non systemd interpreters
17:27:39 <abadger1999> So I think it's badly butchered.
17:27:41 <abadger1999> yeah
17:27:53 <abadger1999> s/interpreters/init system/ :-)
17:28:10 <spot> Okay. I propose that we drop the exception in the guidelines and reword it to only permit the inclusion of sysv init scripts as %doc.
17:28:23 <rdieter> spot: +1
17:28:25 <geppetto> +1
17:28:42 <SmootherFrOgZ> +1
17:28:46 <spot> +1
17:28:48 <limburgher> spot: +1
17:28:52 <tibbs> So we're talking about banning, what, 26 packages here?
17:29:05 <limburgher> I think the main motivation is to wrap up the systemd conversion.
17:29:14 <abadger1999> I don't realy like singling out sysvinit... otoh, sysvinit is in a hard place because systemd will read the sysvinit scripts if there's no matching unit file.
17:29:14 <spot> tibbs: if a package can't be converted, we can always grant an exception.
17:29:23 <abadger1999> err...
17:29:25 <spot> i don't think this is a "comply or gtfo" scenario.
17:29:35 <abadger1999> I didn't think that was what was beinbg asked
17:29:44 <rdieter> the proposal is only to ban sysvinit support from packages that already have systemd units.
17:29:49 <tibbs> I think there are a couple of things being conflated.
17:29:49 <abadger1999> I thought the "separate subpackages" was being asked to be dropped.
17:29:57 <tibbs> One is the separate -sysvinit packages.
17:30:02 <spot> abadger1999: yes, sorry, thats what i was referring to.
17:30:07 <tibbs> The other is packages which have not been converted to systemd.
17:30:09 <abadger1999> If a package provided sysvinit-style init scripts instead of systemd units, it was fine
17:30:15 <spot> abadger1999: yeah.
17:30:30 <tibbs> The title of the ticket and the first sentence talk about different things, which I think is causing confusion.
17:30:44 <spot> Each package that contains software that wants/needs to start a traditional service at boot MUST have a systemd unit file.
17:30:53 <spot> Packages may also provide a SysV initscript file, but are not required to do so. This format is considered legacy, but Fedora still contains init mechanisms such as upstart which do not support the systemd unit file format. If present, the SysV initscript(s) must go into an optional subpackage, so as not to confuse sysadmins. The guidelines for SysV initscripts can be found here: Packaging:SysVInitScript
17:31:14 <spot> thats what the guidelines say now.
17:31:27 <spot> I propose that we change that second section to read:
17:32:00 <abadger1999> tibbs: Sorry.  mea culpa for making the title too generic
17:32:35 <spot> Packages may also provide a SysV initscript file, but are not required to do so. This format is considered legacy. If a package includes a SysV initscript file, it must include it as %doc, and not in the systemd (or old /etc/rc.d/) pathing.
17:34:20 <spot> Thoughts?
17:34:56 <tibbs> I guess I'm trying to understand why 26 packages are shipping -sysvinit subpackages right now.
17:34:58 <limburgher> It's good, I have no objections, I'm just not sure what it buys us, other than pushing a bit harder for migration.
17:35:24 * abadger1999 doesn't like the concept but is fine with the guideline being approved.
17:35:25 <limburgher> Do those 26 have bugs filed?
17:35:28 <spot> limburgher: i think thats all it buys us, but FESCo asked.
17:35:44 <abadger1999> I'll vote +0 unless I'm needed for quorum.
17:35:53 <spot> Lets do a fresh vote on my proposal as worded.
17:35:57 <spot> +1
17:36:01 <rdieter> +1
17:36:01 <limburgher> +1
17:36:01 <geppetto> +1
17:36:02 <abadger1999> +0
17:36:09 <racor> 0
17:36:16 <tibbs> 0
17:36:24 <SmootherFrOgZ> 0
17:36:31 <spot> Okay. So it does not pass.
17:36:33 <tibbs> I mean, I'd be for it if I knew nobody had a good reason for shipping those files.
17:36:50 <spot> Anyone want to put forth any other proposal on this topic?
17:37:01 <geppetto> tibbs: Isn't that the wrong way around?
17:37:01 <spot> Or i can propose that we decline to act on this request.
17:37:09 <tibbs> I mean, for some reason most of our MTAs ship them (sendmail, postfix, exim).
17:37:20 <geppetto> tibbs: Isn't it upto them to come here and argue why we should let them do something different?
17:37:30 <tibbs> Erm, no, it isn't.
17:37:43 <abadger1999> geppetto: Our default is to allow packagers to package things...
17:37:46 <tibbs> I mean, we're talking about just banning things that people are going.
17:38:06 <tibbs> Saying that they should have found out about some meeting and come to argue their case isn't exactly the right way to go about it.
17:38:07 <geppetto> abadger1999: But not randomly …
17:38:48 <spot> Since i'm not hearing people with alternate proposals, I propose that we respond that we have considered a ban and feel that the optional subpackage guideline that exists is sufficient.
17:38:49 <abadger1999> if someone wanted to revive initng and start adding the initng init files, they'd be able to and if it gained enough momentum we'd approve guidelines for how the files should be installed.
17:39:03 <limburgher> spot: Sounds good.
17:39:12 <spot> +1 to my most recent proposal
17:39:13 <geppetto> abadger1999: Really … you want to ship two init systems?
17:39:14 <tibbs> Cron, at, sendmail, mdadm, lvm2... Those are pretty core system components all of which are shipping sysvinit files.
17:39:17 <abadger1999> spot: +1
17:39:24 <abadger1999> geppetto: Want is a strong word there :-)
17:39:49 <abadger1999> geppetto: "allow" is a better statement of my feelings :-)
17:39:56 <geppetto> tibbs: My guess is that none of those need to do that though, and have roughly 0 users for the sub-packages.
17:40:04 <SmootherFrOgZ> +1 on optional subpackage guideline
17:40:13 <abadger1999> We've had multiple init systems in the past.
17:40:14 <tibbs> I would guess that as well, but the point is that, you know, maybe we should ask.
17:40:26 <tibbs> Or is there some urgency here that I'm missing?
17:40:51 <geppetto> Not that I know of
17:41:14 <abadger1999> No urgency that I can se.  Viking_Ice brought it up in the fesco meeting and fesco passed it on to us.
17:41:21 <spot> i see +3 on the latest proposal
17:41:22 <limburgher> Only if systemd is planning on dropping sysv support, which, AFAIK, should be appox. never.
17:41:29 <limburgher> +1
17:41:32 <racor> I read: "if both sysv and systemd" are present, systemd will be used => no urgency for anything.
17:41:39 <rdieter> spot: +1  (i guess, that is the message we're sending by not changing things)
17:41:42 <tibbs> sendmail changelog says "Provided SysV initscript in sysvinit subpackage for backward compatibility".
17:42:05 <spot> hey, +5. anyone else who wants to vote on the record for this, feel free to do so now.
17:42:58 <spot> #action FPC has considered a ban and feels that the optional sysvinit subpackage guideline that exists is sufficient. (+1:5, 0:0, -1:0)
17:44:01 <geppetto> -1
17:44:04 <spot> Aside from bundling requests, I think thats it.
17:44:11 <spot> #topic Open Floor
17:44:27 <spot> oh wait, sorry. 252.
17:44:39 <spot> #topic Simplify github guidelines - https://fedorahosted.org/fpc/ticket/252
17:44:42 <tibbs> Someone had pinged me about 241 as well.
17:45:02 <spot> sochotni: could you please propose a specific change in wording for us? that makes it much simpler for us to consider and vote on
17:45:04 <tibbs> Oh, github actually fixed something?
17:45:21 <tibbs> I'm all for supporting it, whatever it is.
17:45:27 <sochotni> tibbs: :-)
17:45:31 * limburgher checks temp in hades
17:45:39 <sochotni> spot: I could whip something up, but I guess not before the meeting is over
17:45:48 <spot> sochotni: we'll tackle it first thing next week
17:46:04 <sochotni> sure, it's low prio but I noticed a lot of people are not aware still
17:46:32 <sochotni> and I thing a working Source0 URL is going to be a nice change
17:46:43 <tibbs> I certainly agree.
17:46:44 <limburgher> Very. :)
17:46:53 <spot> i think we all agree, just looking for the simple wording change. :)
17:47:14 <tibbs> If we get enough votes in the ticket it can go ahead before the meeting.
17:47:18 <abadger1999> <nod>
17:47:40 <sochotni> OK, I'll update stuff in the ticket then
17:47:49 <spot> #topic Clarification request: Acceptable use of explicit Conflicts - https://fedorahosted.org/fpc/ticket/241
17:48:32 <tibbs> Honestly I do not know what anaconda and fedup do here.
17:48:33 <geppetto> again … I'm for the idea presented in the ticket, but having some text would be nice.
17:48:35 <spot> I've read this a few times, and I'm still not sure I understand why the Conflicts is necessary.
17:48:51 <limburgher> Why not just make the new package f18+ only?
17:48:53 <geppetto> spot: Can't upgrade from F17 to F18 without it.
17:48:55 <spot> if the package is F17 only, and F18 has a package which Provides/Obsoletes it
17:49:07 <spot> why the Conflicts?
17:49:24 <geppetto> For the packages that exist before the obsolets … ie. F18 GA
17:49:28 * limburgher retracts my last comment
17:49:53 <spot> geppetto: not following
17:50:33 <geppetto> spot: There exists an N1-1 in F18 that can't be installed at the same time as their package.
17:50:37 <tibbs> The last paragraph seems to misunderstand what's written in the guidelines.
17:50:54 <geppetto> spot: They need to conflict with that. But N1-2 will come out which will also obsolete them.
17:51:29 <limburgher> If N1-2, why the need for a Conflict?
17:51:39 <spot> geppetto: what I don't understand is why they cannot first push an update to F18 that does the provides/obsoletes
17:51:45 <limburgher> spot: this.
17:52:29 <geppetto> spot: I assume it's just a "people try to do 'F17+updates => F18' yum upgrades ... this will tell them it's not going to work"
17:52:46 <limburgher> Not if they do spot's prior update.
17:52:58 <spot> geppetto: as opposed to yum telling them "these files conflict, i can't do it" now? :)
17:53:03 <geppetto> limburgher: That requires F17+updates => F18+updates
17:53:03 <abadger1999> geppetto: Will that succeed if you "s/yum/fedup/"?
17:53:08 <geppetto> spot: yeh
17:53:26 <geppetto> spot: file conflicts are post download though.
17:53:57 <limburgher> geppetto:  Why not just F17=>F18+updates?  The update in F18 could handle it correctly.
17:54:11 <geppetto> abadger1999: Not 100% sure, but I don't think fedup requires F18 updates be available.
17:54:11 <limburgher> Sorry, F17*
17:54:23 <spot> I don't think this merits an explicit Conflicts, this is something where we just advise that people doing yum dist upgrades enable updates to ensure the best possible outcome.
17:54:32 * geppetto nods
17:55:08 <limburgher> spot:  Which is something I can't imagine they wouldn't want to do anyway, if only for security fixes.
17:55:23 <geppetto> limburgher: I assume just that people don't always enable updates, for whatever reason … and they are just trying to make it be "the best" they can.
17:55:33 <spot> The only advantage of an explicit Conflicts is to stop the transaction before downloads start.
17:55:41 <limburgher> geppetto:  Seems like more churn to do it that way.
17:56:10 * geppetto shrug … I assume the conflicts is pretty much free, as they haven't released the package yet.
17:56:14 <limburgher> And they need the downloads anyway.
17:56:23 <geppetto> But I'm also not bothered if we'd rather they not have conflicts.
17:57:06 <geppetto> There's no changed text to vote on anyway...
17:58:13 <spot> So, I propose that we advise that in this situation, we recommend that the guidance on doing yum dist upgrades be amended to recommend enabling the updates repo and that proper Provides/Obsoletes are used for the F18 package.
17:58:27 <limburgher> +1
17:59:29 <tibbs> +1
17:59:31 <abadger1999> +1
17:59:36 <spot> https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#5._Make_sure_Fedora_is_upgraded is the closest thing to guidance we have, so if anyone wants to insert "turn on the updates repo", it would be appreciated.
17:59:49 <geppetto> +1
17:59:50 <racor> +1
17:59:54 <SmootherFrOgZ> +1
17:59:56 <tibbs> But I guess there's a question as to whether our guidelines are clear enough here.
17:59:56 <spot> +1
18:00:35 <rdieter> +1
18:01:01 <limburgher> tibbs: I'm trying to decide whether I think that, or if it's simply a difference of understanding about technical capability.
18:01:26 <spot> If someone wants to reword that section (again), please open a new ticket. :/
18:01:42 <tibbs> I don't know; I understand it just fine.
18:02:01 <limburgher> I meant between the participants in the review. :)
18:02:40 <tibbs> Last paragraph of this ticket indicates they don't seem to like the "as a general rule, you must not use conflicts" bit.
18:02:50 <tibbs> But I don't see what's wrong with it.
18:03:11 <limburgher> Me neither.  Conflicts are almost never the right way to solve a problem.
18:03:15 <spot> #action No Conflicts, use proper Provides/Obsoletes, and turn on updates repo when dist-upgrading (+1:8, 0:0, -1:0)
18:03:40 <spot> if someone would be so kind as to amend that Upgrading_Fedora_using_yum page, I would appreciate it
18:03:49 * spot has 2+ weeks worth of backlog work
18:04:11 <spot> #topic Open Floor
18:04:17 * kalev raises a hand.
18:04:21 <kalev> I have a quick issue, regarding the the vendor tag removal from the desktop files:
18:04:24 <spot> kalev: sure.
18:04:29 <kalev> "< spot> I propose that we amend the guidelines to say that for Fedora 19 and beyond, the vendor tag must not be used. If it was being used in a previous release, it may continue to be used for that previous release, but must be removed in Fedora 19. New packages must not add the vendor tag for any release."
18:04:34 <kalev> Can you amend this to make it clear that the desktop file name shouldn't be changed in a stable Fedora release?
18:04:40 <kalev> Right now the "it may continue to be used for that previous release" reads as if it was okay to change the desktop file name in F16-F18
18:04:45 <kalev> Maybe explicitly say "Do not change the desktop file name in a stable Fedora release." or something?
18:04:48 <kalev> Otherwise looks good to me.
18:05:04 <spot> kalev: sure, thats the intent of that wording, so I don't think it hurts to say that.
18:05:21 <kalev> great, thanks
18:06:00 <spot> How about "Packagers are reminded that they must not change the name of the desktop file in a stable Fedora release."
18:06:15 <kalev> Sure, sounds good
18:06:27 <spot> Quick vote on that addendum text?
18:06:28 <spot> +1
18:06:50 <geppetto> +1
18:06:58 <tibbs> +1
18:07:17 <tibbs> Not sure enough folks are still around, though.
18:07:33 <SmootherFrOgZ> +1
18:07:35 <spot> i know we lost several folks to fesco
18:08:16 <limburgher> +1
18:08:20 <spot> hey, +5!
18:08:33 <spot> #action addendum to vendor tag item approved (+1:5, 0:0, -1:0)
18:08:59 <spot> okay, lets go ahead and close out for this week. Thanks everyone, this was a productive meeting! :)
18:09:06 <spot> #endmeeting