Packaging:Minutes20080506

Present

 * JasonTibbitts
 * RalfCorsepius
 * RexDieter
 * TomCallaway
 * ToshioKuratomi
 * XavierLamien

Votes
The following proposals were considered:


 * Tracking the upstream status of patches
 * http://fedoraproject.org/wiki/PackagingDrafts/PatchUpstreamStatus
 * A new draft this week.
 * Accepted (5 - 1)
 * Voting for: spot SmootherFrOgZ tibbs rdieter abadger1999
 * Voting against: racor


 * Mandatory verification of desktop files
 * http://fedoraproject.org/wiki/PackagingDrafts/DesktopVerify
 * A new draft this week, modifying the existing guidelines.
 * Accepted (6 - 0)
 * Voting for: spot rdieter hansg (on-list) abadger1999 tibbs SmootherFrOgZ

Other Discussions
A proposal to change the meeting time to 15:00UTC (two hours earlier) was discussed and will be further discussed via email.

IRC Logs
[12:03] So, FPC? [12:04] spot: ? [12:04] * spot is here [12:05] ok, i see rdieter and tibbs are here too [12:07] * SmootherFrOgZ is here [12:07] racor, abadger1999? [12:07] 3/4 here. [12:08] * abadger1999 is in an ad hoc meeting about pkgdb as well. [12:08] i don't see Rathann or delero [12:09] * abadger1999 pings rathannin f-devel [12:09] I am almost absent, this time slot simply doesn't work for me :( [12:10]  racor: http://fedoraproject.org/wiki/Packaging/NewMeetingTime doesn't have any entries from you [12:10]  (or anyone else, for that matter) [12:11]  well, ok, i see abadger1999's blanket acceptance. :) [12:11] spot: I wrote a note that all those times are good for me. [12:11] heh :-) [12:12]  I don't have significant restrictions, either. [12:12]  ok, well, with 3/4 abadger1999 and almost absent racor, that is quorum [12:12]  we don't have very much on the agenda today [12:12]  http://fedoraproject.org/wiki/PackagingDrafts/PatchUpstreamStatus [12:12]  ^ first item [12:13]  I like the idea; my proposal for extending it to arbitrary metadata didn't gain traction so I guess this one wins. [12:13]  Ambivalent.  Comments == Good.  Should items are always kind of wishy-washy, though. [12:13]  Certainly not a requirement, though. [12:13]  if it encourages people to do it, i'm supportive of it. [12:13]  spot: I don't see any need to vote. We once had decided to switch meeting time with DST, but this hasn't happened. [12:14]  racor: ok, let me be a bit more specific, would 15.00 - 16.00 work better for you? [12:15]  15:00 UTC, that's 17:00 CEST - much better [12:16]  i'll send out email proposing that we switch to that time slot, we'll see if everyone can make that work. [12:16] 10AM for me; doable most of the time. [12:16] good here too [12:16] better than now even. :) [12:16] ok, lets vote on http://fedoraproject.org/wiki/PackagingDrafts/PatchUpstreamStatus [12:16]  +1 from me [12:17]   +1 [12:17]  +1 although I will still present a proposal for extending it in the future. [12:17]  tibbs: you know how we roll. ;) [12:18] +1, though nervous about slippery slope of wishy-washy common-sense items in guidelines. [12:18] -1, personal preference/stylishness, should not be made part of theFPG [12:18] +1 [12:18]  racor: srsly? prefer *not* to document patch status? [12:19] Well, if we waht to have tools that gather these, then we at least need to document what the tools will accept. [12:19] ok, thats +5 to the draft [12:19] abadger1999: is Javascript ready? [12:19] rdieter: common sense should direct maintainers to document patches at *their* preference. [12:19] Honestly I believe that it would be better for the tools to exist first, but nobody but me seems interested so I'll just make them accept what this draft suggests. [12:19] racor: isn't that what a SHOULD means? [12:20] racor: How does this guideline not do that? [12:20] spot: No. I haven't had time to package another library up. [12:20] tibbs: I'd be interested in seeing your patch metadata in these comments. [12:20] tibbs: orthogonal, this doesn't need to block on tools existing or not (tho tools would certainly be preferable) [12:20] rdieter: I see the SHOULD, ... [12:20] abadger1999: BTW, it was indicated to me that it's spelled "JavaScript". Not that I particularly care. [12:21] tibbs: Yah. I need to do that and include the comments from the last meeting. [12:21] * abadger1999 fixes spelling now since it's easy [12:21] okay. thats all i have on the agenda for today. [12:21] I recall an on-list proposal that people were discussing. [12:22] tibbs: which one? [12:22] I forgot to tick it so the article expired from my folder. There was no draft, so.... [12:22] caillon had posted awhile back wondering if desktop-file-validate could be added, anyone's feelings change since that was discussed way back when? [12:22] Maybe that was it. [12:23] rdieter: oh, yes, i remember that [12:23] can't pull up the archive, redhat.com is down. heh. [12:24] rdieter: I'm +1 to that proposal. [12:24] Since the purpose of this guideline is to validate, I propose to amend the section of the packaging guidelines on desktop-file-install usage[1]  as follows: [12:24] * Rename the sub-heading from "desktop-file-install" to ".desktop file installation and validation" [12:24] * Change the first sentence to: [12:24] << [12:24]  It is not simply enough to just include the .desktop file in the [12:24] he wanted this added as an example of d-f-* usage:    desktop-file-validate %{buildroot}/%{_datadir}/applications/foo.desktop [12:24] package, one MUST run desktop-file-install OR desktop-file-validate in [12:24]  %install (and have BuildRequires: desktop-file-utils), to help ensure [12:24] .desktop file safety and spec-compliance. desktop-file-install MUST be [12:24] used if the package does not install the file or there are changes [12:24] desired to the .desktop file (such as add/removing categories, etc). [12:24] desktop-file-validate MAY be used instead if the .desktop file's content/location does not need modification. Here are some examples of usage: [12:24] >> [12:24]  * Add the following example: [12:24] <<   desktop-file-validate %{buildroot}/%{_datadir}/applications/foo.desktop [12:24] (sorry for the mini flood) [12:25] seems pretty obviously correct to me. [12:25] I'm ok with that too: +1 [12:25] hans had an onlist +1 [12:26]  hm, that could be a feature for rpmlint (?) [12:26] +1 [12:27]  ok, i see +4 total on this proposal [12:27] Actually it could be a rpmbuild script as well, I guess. [12:27]  i'm ok with that too [12:28] This is yet another thing that probably shouldn't have to be done explicitly, but until we get there I have no problem requiring, so +1. [12:28] I got to go, bye ... [12:28] ok, thats +5. anyone else want to get a vote for the record? [12:29]  +1 from me [12:29]  alright, any other issues for today? [12:29] Can someone write this up into an actual draft? [12:29] i will. [12:30] ok, i think we're done for today. [12:30] thanks all [12:31] Thanks spot