From Fedora Project Wiki

Fedora Packaging Committee Meeting 2009-03-31

Present

  • Jason Tibbitts (tibbs)
  • Rex Dieter (rdieter)
  • Tom Callaway (spot)
  • Toshio Kuratomi (abadger1999)
  • Xavier Lamien (SmootherFrOgZ)

Regrets

  • Denis Leroy (delero)
  • Dominik Mierzejewski (Rathann|work)
  • Hans de Goede (hansg)
  • Ralf Corsepius (racor)

Votes

The following proposals were considered:

Other Discussions

The following additional items were discussed; see the logs for full details.

  • Meeting time
    • A proposal will be floated to change the meeting time to a two hour block at 15:00UTC on Wednesdays.

IRC Logs

*** spot sets the channel topic to "Fedora Packaging Committee". 12:01
spot rdieter, abadger1999, SmootherFrOgZ, tibbs: ping 12:03
tibbs Howdy. 12:03
abadger1999 pong 12:03
rdieter yo 12:03
abadger1999 apologies, I didn't get a chance to update the conflicts guidelines. 12:04
spot well, racor said he wasn't coming due to the time change 12:05
spot I don't see Rathann or delero 12:05
tibbs The time is back to what is was previously. 12:05
spot and I don't think SmootherFrOgZ is around 12:05
spot i'll give it a few more minutes, but we do not have quorum 12:06
* SmootherFrOgZ is 12:06
spot aha! 12:06
spot okay, great! :) 12:06
spot first item: https://fedoraproject.org/wiki/Common_package_names_packaging_guideline_draft 12:07
spot ... but, abadger1999 hasn't had a chance to update them 12:08
* spot is awake, honest. 12:08
abadger1999 yeah 12:08
spot okay, lets move on to the next item: https://fedoraproject.org/wiki/Publican_Documentation_Packages 12:09
spot i'm not a huge fan of embedding .desktop files in the spec 12:09
tibbs I don't have a problem with it. 12:09
tibbs It is not uncommon to embed short source files in the spec. 12:10
abadger1999 I've been talking with docs about this. there's really two parts. I don't have a problem with either. 12:10
* spot won't vote against it for that, but I think it makes the spec less manageable 12:10
tibbs I think it's a rather poor idea to embed the version in the package name, however. 12:11
SmootherFrOgZ i also don't, but i'd prefer to manage it outside of the spec 12:11
spot i think that abadger1999's suggestion at the bottom of the draft is preferable than exception casing it for Publican 12:11
spot although, it is worth leaving the example in 12:11
tibbs Do our guidelines actually forbid echo >> blah.desktop <<END in a specfile currently? 12:12
abadger1999 tibbs: The justification for that is that the "Fedora 11 XXX Guide" is a different document from the "Fedora 12 XXX Guide" 12:12
spot tibbs: i don't think so 12:13
tibbs abadger1999: Just like gcc 4 is different from gcc 3. 12:13
abadger1999 tibbs: Although docs is trying to convince the publican application authors to allow them to leave the version number out if they want. 12:13
abadger1999 tibbs: Well... If you think of it as a book, it makes more sense. 12:13
tibbs It doesn't really make more sense to me. 12:13
tibbs A book can have a version, sure. 12:14
tibbs But we have well-established method for dealing with things that have versions. 12:14
spot do these packages conflict (diff versions of same manual)? 12:14
abadger1999 It's not the book that has the version in this case... The book is about a different version of the software. 12:14
abadger1999 (In our case, Fedora 11 vs Fedora 12). 12:15
abadger1999 spot: No conflicts. They're meant to be parallel installed. 12:15
spot will they actually be maintained across multiple branches in parallel? 12:15
abadger1999 That's the idea (from the publican side). 12:15
tibbs And they are making a promise to provide a new one for each Fedora release? 12:16
tibbs Because when you name things that way, you're making an implicit promise. 12:16
spot well... this is close to the "Multiple packages with the same base name", but not quite. 12:16
abadger1999 The docs folks have agreed that they may want to do that for some packages (Like release notes and install guide) but want to talk the publican authors into going version-less for Security Guide and such. 12:16
tibbs If you just have version 2 of the document, it doesn't imply any link to any particular Fedora version. 12:17
spot I'm not really buying the OS version embedded in the name... 12:17
spot we have the %{?dist} tag explicitly for that 12:17
tibbs If you name the document after the Fedora version, then you get users who want the F13 version and not the moldy F12 version. Sort of like the problem we have with dist tags now. 12:17
abadger1999 I've got a few docs folks coming over. 12:18
abadger1999 jjmcd and ke4qqq. 12:18
abadger1999 tibbs: I agree that it doesn't make nearly as much sense if we aren't making a new package for each new release. 12:19
spot i'm just not sure what the value of having the Fedora10-HowToFooAndBar in the f-12 branch is. 12:19
spot especially if there is also a Fedora11-HowToFooAndBar and Fedora12-HowToFooAndBar in the f-12 branch too 12:19
ke4qqq spot: how about having Fedora12-howtofooandbar in the f-10 branch? 12:19
spot ke4qqq: how could that possibly be useful? it would refer to changes that are not necessarily present 12:20
ke4qqq which strikes me as more likely scenario 12:20
spot it would be far useful to have a single version in each branch that is kept current and relevant for that branch 12:20
ke4qqq it's possible that I am reading documentation on my local machine on f10 while getting ready to upgrade my machine or machines I manage 12:20
f13 which you can easily do from the website 12:21
jjmcd You don't see sysadmins who have more than one version on their network wanting to access documentation for all their boxes? 12:21
tibbs It's not as if the other versions can't be online somewhere. 12:21
tibbs The other thing is that we'll end up with the F10 version still around on F22 unless someone keeps remembering to get rel-eng to block the old ones. 12:21
tibbs And they will sit around in CVS forever. 12:22
tibbs It just doesn't seem to scale well to me. 12:22
ke4qqq if we followed that to it's logical end then why would we have the documentation locally at all? 12:22
ke4qqq the scaling and aging is a valid concern 12:22
spot well, if Fedora docs is responsible for blocking old docs... 12:23
spot perhaps it could go in one of the checklists 12:23
spot my other concern is that I don't want the OS version embedded in publican docs just because they came out of publican 12:24
tibbs It's just one more thing to do. I know we're not responsible for policy in that area, but shouldn't folks generally try to minimize that kind of thing. 12:24
spot if the docs aren't Fedora distribution version specific, they shouldn't do that 12:24
spot (this might be how it works now, but the guidelines seem to imply that all Publican docs have this behavior) 12:25
f13 yeah, it seems like the reasons are just excuses for not fixing the publican flaw 12:25
abadger1999 To me, these are packages of content. Which doesn't always fit the software-packaging model. 12:25
jjmcd f13: I see both use cases, but honestly, I don't understand why Publican insists on the version number 12:25
abadger1999 I'd rather the docs team had control over the "Should we package these docs that are specific/pretend to be specific to each release". 12:26
spot abadger1999: i would prefer that to permitting all publican generated docs to have the Fedora version embedded in %{name} 12:26
abadger1999 <nod> 12:27
spot if docs wanted to maintain multiple versions of the same docs with the existing base name exception in NamingGuidelines, they could do so now 12:27
spot e.g. HowToFooAndBar & HowToFooAndBar-Fedora11 12:28
abadger1999 So do we need any language at all? Perhaps just let docs know that there's no issue with having the Fedora Release number as part of the title/name of their doc but we think there's issues they might want to consider? 12:28
jjmcd Most (but not all) of our docs are specific to the release, so it makes some sense to have the Fedora version in the name, but we also need to get Publican fixed for the other use case 12:28
f13 well, one thing is that it'll break anything wanting to require "fedora-release-nots" 12:28
f13 er "fedora-release-notes" 12:28
abadger1999 jjmcd: Does that seem like a reasonable statement? 12:29
abadger1999 f13: Virtual Provide? 12:29
jjmcd Does anything do that? 12:29
f13 anything requiring them, or putting them in comps, or kickstarts, etc.. will have to constantly edit them to embedd a version 12:29
f13 abadger1999: which one wins? 12:29
abadger1999 f13: Any :-) 12:29
f13 it's a concern to consider. 12:30
spot f13: yeah, i think that the current version for a branch should not have the version embedded in it 12:30
* abadger1999 checking repoquery 12:30
spot i don't have a problem with it doing Provides: FooBar-Fedora12 12:30
spot to me, it feels less like we're trying to document a valid use case and more like we're hacking around a broken tool 12:31
jjmcd I think we have both going on, actually 12:31
spot in all fairness, we've permitted guidelines to hack around broken tools in the past 12:32
ke4qqq spot: that echoes a lot of the sentiment within docs as well, yet the use case, at least at first blush seems valid 12:32
f13 we already have guidelines that allow for the broken behaviouir 12:32
spot so there is precedent here, but I am reluctant to permit too broad of an exception 12:32
spot If the documentation is really Fedora version specific AND the docs team feels there is a need to have multiple versions in the same branch, then and only then, they should be able to do so 12:33
spot But as a general case, to simply permit all publican docs to be sloppy, no... i don't think so. 12:33
abadger1999 repoquery --whatrequires fedora-release-notes 12:33
abadger1999 fedora-release-0:10-1.noarch 12:33
spot [spot@velociraptor sandbox]$ repoquery -q --whatrequires --alldeps fedora-release-notes 12:33
spot lynx-0:2.8.6-20.fc11.x86_64 12:33
abadger1999 That's already a virtual provide, though. 12:35
spot ke4qqq/jjcmd: does that statement make sense? 12:35
jjmcd which statement 12:35
ke4qqq spot: it makes sense - I almost wonder if we should be inferring that you want us to ask for specific documents/packages to provide exceptions to, rather than a general guideline 12:35
spot "If the documentation is..." "But as a general case..." 12:36
jjmcd yes, I think that is good 12:36
spot Well, I'm not sure how we would setup the requests. 12:36
spot We could change the text to something like: 12:37
ke4qqq neither am I..... we'll be happy with the above dispensation I believe. 12:37
ke4qqq at least as happy as we can be with the tool in the condition it is in. 12:37
jjmcd Yes, I think it reminds us to get the tool fixed 12:38
spot "Documentation packages (as approved by the Fedora Documentation SIG) can be named with the OS version number in the package name to allow parallel installation of multiple versions, in cases where the documentation is specific to a release of Fedora and there is value in having multiple versions simultaneously installed." 12:38
spot That opens the window a bit, but not so wide that trucks are driving through it. 12:39
jjmcd Fedora Documentation Project rather than SIG 12:39
ke4qqq perhaps s/SIG/subproject/ 12:39
spot sorry. guessed wrong. :) 12:39
spot "Documentation packages (as approved by the Fedora Documentation Project) can be named with the OS version number in the package name to allow parallel installation of multiple versions, in cases where the documentation is specific to a release of Fedora and there is value in having multiple versions simultaneously installed." 12:39
jjmcd Forgiven: You don't call it DocsProject 10 times a day 12:39
ke4qqq worksforme 12:40
abadger1999 I like that. Leaves the docs project in charge with a clear idea of when it is or is not appropriate. 12:40
jjmcd Well Eric come lately 12:40
Sparks_Too :) 12:40
spot so, give me a second, I'm going to break this into two drafts 12:40
jjmcd spot just now articulated the rule and we all agreed to sell the farm in your absence 12:41
Sparks_Too jjmcd: You can sell the farm... just don't sell the ship. 12:41
spot https://fedoraproject.org/wiki/PackagingDrafts/DocumentationNaming 12:42
spot FPC folks, what do you think about it? 12:42
abadger1999 +1 12:43
abadger1999 I like it. 12:43
SmootherFrOgZ sound good to me 12:43
tibbs So how many of these things are going to be dumped on the review queue every release? 12:44
* Sparks_Too takes a look 12:44
tibbs With some reasonable packaging guidelines they should be trivial to review, but the reviewers are increasingly over-over-overloaded. 12:44
abadger1999 A related question would be -- does docs have the manpower to both package and review them? 12:45
Sparks_Too spot: I'm not sure we have an approval process. 12:45
ke4qqq abadger1999: yes 12:45
tibbs The queue has grown by 50 packages in the last two weeks. 12:45
abadger1999 Cool. 12:45
Sparks_Too spot: What should we be looking at to approve? 12:45
ke4qqq we'll take responsibility for reviewing docs produced stuff - we have enough packagers floating around to handle that sanely I think. 12:45
spot Sparks_Too: if it were me, i would ask "is this documentation really version specific? is there value in having multiple releases in the same dist at once?" 12:46
spot by version, i mean "OS version" 12:46
jjmcd I think there is more value being able to install than having in the dist e.g. --enablerepo 12:48
jjmcd Nice to install for example rawhide RNs without clobbering my current copy 12:48
spot well, i'm content to defer that decision to Fedora Docs 12:48
spot they're going to bear the majority of that burden anyway 12:49
spot if it becomes unbearable, we can always revisit this 12:49
Sparks_Too spot: Okay, I can do that. Should we look at anything else prior to submitting it for review? 12:49
spot Sparks_Too: i suppose that is up to Fedora Docs. Of course, it needs to meet the rest of the Fedora Packaging and Naming guidelines 12:50
Sparks_Too spot: I foresee a problem coming down the road. Each language is packaged independently. So that's going to mean a lot of packages hitting the review process within a short amount of time. 12:50
ke4qqq yeah I was about to bring that up as well. 12:50
spot Sparks_Too: each language is packaged independently? 12:50
spot seriously? that's just broken. 12:51
Sparks_Too spot: Yes 12:51
ke4qqq another tool issue 12:51
tibbs Oh, please no. 12:51
spot yeah, i'm not going to let that slide. 12:51
Sparks_Too spot: In RH the reasoning is so there aren't 200MB docs... 12:51
ke4qqq I suspect it's a plot to dramatically increase fedora package count :) 12:51
Sparks_Too being downloaded for just one language. 12:51
spot learn about subpackages. 12:51
Sparks_Too So you would be able to install a language versus a document. 12:51
Sparks_Too If that makes sense. 12:51
abadger1999 subpackage ++ 12:52
ke4qqq right, single srpm, 35 rpms 12:52
Sparks_Too ke4qqq: This is a RH thing and not a Fedora thing. 12:52
spot subpackages should be fine 12:52
spot 35 base packages would not be 12:52
Sparks_Too spot: Okay, not familiar but would be. 12:52
Sparks_Too s/would/will 12:52
spot Sparks_Too: basically, think of how the openssl package generates openssl and openssl-devel 12:53
spot it is just one package for review (openssl) 12:53
spot HowToFooAndBar could generate HTFAB-en and HTFAB-de 12:53
Sparks_Too spot: Okay... so would we need ALL the languages in the package before it is approved? 12:54
tibbs No. You can just add a language once the package is in. 12:54
spot Sparks_Too: nope. you can add subpackages as they are done. 12:54
spot FPC, we're almost out of time 12:55
Sparks_Too spot: Okay. That works for me. Our meeting is tomorrow so I'll bring it up then. I don't have a problem with any of this, just need to learn more. 12:55
spot can we vote on: https://fedoraproject.org/wiki/PackagingDrafts/DocumentationNaming ? 12:55
spot +1 from me 12:55
abadger1999 +1 12:55
SmootherFrOgZ +1 12:55
tibbs +1 12:56
spot tibbs, rdieter? 12:56
rdieter +1 12:56
spot okay, it passes 12:56
spot next item: https://fedoraproject.org/wiki/PackagingDrafts/EmbeddedDesktopFiles 12:56
spot that is the second half of the original Publican Draft 12:57
abadger1999 .+1 12:57
SmootherFrOgZ +1 12:57
spot +1 12:57
tibbs I don't see why we need to talk about this at all. 12:57
tibbs The language is fine, so +1 for that if folks really think we need to say something about it. 12:58
spot tibbs: i think it was not clear to some people that this was permissable. 12:58
tibbs I suppose because we mention SOURCE3 in the example and folks assumed that you couldn't just put a file name there? 12:58
SmootherFrOgZ tibbs: :) 12:59
spot rdieter: ? 12:59
abadger1999 tibbs: Yeah, the original explicitly said include a .desktop file... If I was smarter, I would figure out how to remove the file/inline mention altogether. 13:00
rdieter +1 13:02
spot okay, thats +5 it passes 13:02
rdieter abadger1999: nod 13:02
spot next item: https://fedoraproject.org/wiki/User:Ianweller/WordPress_plugin_packaging_guidelines_%28draft%29 13:02
spot this looks okay to me, with the caveat that if any wordpress plugins aren't noarch somehow, they'd need to be adjusted accordingly 13:03
spot i know nothing about the format of wordpress 13:03
abadger1999 This looked pretty good to me too. 13:04
abadger1999 spot: ianweller was going to ask you about the licensing note in the spec file. 13:04
spot I'm going to go ahead and vote +1 13:04
abadger1999 Is that okay? 13:04
SmootherFrOgZ i'd just add a -p flag to cp, to keep timepstamp of some files 13:04
tibbs It wasn't on the todo list so I need to read it. 13:04
SmootherFrOgZ +1 13:04
rdieter +1 13:04
spot abadger1999: assuming they come from that repo, yes. 13:04
abadger1999 +1 13:05
spot abadger1999: its loose licensing intent, but intent nevertheless 13:05
abadger1999 Okay. 13:05
spot tibbs: go ahead. 13:05
tibbs So should I assume that the two wordpress variants can't change to just get their plugins from a common directory? 13:05
spot tibbs: that would be logical, eh? :) 13:06
tibbs SmootherFrOgZ: cp -a implies -p. 13:06
tibbs Actually it implies -dpR. 13:07
tibbs So I don't have a problem with this, but wouldn't it be prudent to at least ask the wordpress packagers if there's any possibility of a shared plugin directory? 13:08
tibbs Maybe that's already been done; I'm not familiar with this issue. 13:09
abadger1999 We could kick that back to ianweller to find out. 13:09
SmootherFrOgZ tibbs: afaik, wordpress-mu is a bit different than wordpress, but we should ask wordpress folks or ianweller directly 13:10
spot sure, lets do that 13:10
SmootherFrOgZ abadger1999: nod 13:10
abadger1999 I suppose it depends on whether the variants are in the process of diverging or converging. 13:10
tibbs Well, the thing is that this guideline sort of assumes that they take the same plugins. 13:10
spot especially given that the spec template shows it copying the files. :) 13:10
tibbs If that's something that we know is going to change then it would be better to get it right now rather than having to go back to this guideline when things change later. 13:11
spot we should ask ianweller whether there will be any divergent cases where the mu plugin is different from the normal wordpress plugin 13:11
spot if not, then they should use a common dir 13:11
abadger1999 I asked him that and he said theoretically but none yet. 13:12
tibbs The other alternative is to make them search a common dir and then variant-specific dirs. 13:12
abadger1999 <nod> 13:12
tibbs Or the other way around; whatever. 13:12
tibbs But that gets into internals which might not be easy to change. Best to at least ask about it. 13:13
spot yeah, lets at least ask about it. if the answer comes back as no, we can probably vote over email 13:13
spot okay, so that was the last item i saw on the agenda 13:14
spot are there any other items? 13:14
tibbs Do we want to talk about the meeting time, given Ralf's message? 13:14
tibbs Have we ever succeeded in getting from him a time which would be better? 13:15
spot i don't think so 13:15
tibbs I recall asking but not receiving a response. 13:15
tibbs Not much we can do about it, then. 13:16
spot i think we'd have to go earlier, but we can't go too much earlier because abadger1999 is on US Pacific 13:16
spot its a rather small window. :/ 13:16
abadger1999 I can do it earlier than now (time change) 13:16
tibbs My brain can't wrap around the time changes. 13:16
spot abadger1999: two hours earlier? 13:16
abadger1999 Right now we're starting at 10AM Pacific. 13:16
* abadger1999 makes hand wavy motions 13:17
tibbs Was the last meeting an hour earlier for Europeans or an hour later? 13:17
abadger1999 Mostly I can do 8AM Pacific. 13:17
spot tibbs: earlier, i think 13:17
abadger1999 Unless my daughter misses the bus or similar. 13:17
SmootherFrOgZ tibbs: earlier 13:18
spot but we can't just go one hour earlier because of rdieter's kde sig conflict 13:18
spot unless we change the day 13:18
spot so we have to go two hours earlier 13:18
tibbs KDE has said that they're flexible, but I don't want to try and push them around. 13:18
tibbs It's unfortunate that it's worked out this way but I don't know what else we can do to accommodate Ralf. 13:19
spot tibbs: can you send out an email to everyone proposing that we move to 1500 UTC on tuesday? 13:19
spot see if anyone complains 13:19
tibbs The other problem is that we frequently run over time. 13:20
tibbs Currently we have nobody meeting after us. 13:20
abadger1999 <nod> That is a great benefit 13:20
SmootherFrOgZ so, could the best way be change the day ? 13:20
tibbs We'd have to change the day and the time. 13:21
spot maybe. go earlier and change the day 13:21
tibbs Bugzappers is in this channel at 1500UTC. 13:21
tibbs on Tuesdays. 13:22
tibbs 1500 is free all other days. On Wednesdays, 1600 is free as well. 13:22
spot yeah, we can't go earlier and not have someone after us 13:22
spot but we could always move out into some other channel if we ran over 13:22
spot (unless we went two hours earlier on wednesday) 13:22
tibbs Well, we can take two hours on Wednesdays at 1500. 13:22
spot i could do that 13:23
tibbs That's the only day where that works. On Thursdays we can take 1.5 hours. 13:23
tibbs But that puts us close to FESCo again. 13:23
spot FESCo is friday 13:23
spot they still would have two days, effectively. 13:23
tibbs Yes, but we want more than one day between us and them. 13:24
tibbs So Thursday is out but Wednesday is ideal. 13:24
tibbs I'll propose Wednesday at 15:00 UTC. 13:24
spot sounds like a plan. 13:24
tibbs Would anyone who is here object to that? 13:24
* spot hears no objections 13:26
spot i also don't hear any other items for today, so i will close out the meeting 13:26
spot thanks everyone 13:27
tibbs I'm off for food. 13:27
SmootherFrOgZ thanks all 13:28
Retrieved from "https://fedoraproject.org/w/index.php?title=Packaging:Minutes/20090331&oldid=94912"