From Fedora Project Wiki

Fedora Packaging Committee Meeting of {2008-06-03}


  • DenisLeroy (delero)
  • HansdeGoede (hansg)
  • JasonTibbitts (tibbs)
  • RalfCorsepius (racor)
  • RexDieter (rdieter)
  • TomCallaway (spot)
  • ToshioKuratomi (abadger1999)
  • XavierLamien (SmootherFrOgZ)


No new guidelines this week.


No votes this week.

Other Discussions

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

  • Early discussion on possible packaging harmonization with SuSE.
  • Issues with wiki ACLs

IRC Logs

* spot looks around 12:07
spot racor, abadger1999, rdieter, SmootherFrOgZ, tibbs: ping 12:09
tibbs yep 12:09
rdieter here 12:09
spot i don't see Rathann or hans 12:10
SmootherFrOgZ here 12:10
--> delero has joined this channel (n=denis@nat/sun/x-dc1122e068355ed1). 12:10
abadger1999 pon 12:11
* delero is here 12:11
abadger1999 Yeah, here. 12:11
spot i count 6 present and alive. :) 12:11
spot So, looking at GuidelinesTodo, i don't see... anything. 12:12
spot thus, i'll open the floor to any other items. 12:12
--> hansg has joined this channel ( 12:13
abadger1999 rdieter: What happened to the .dekstop stuff you and mclassen wanted to change? 12:13
hansg A bit late but I'm here (thanks for the ping Xavier) 12:13
SmootherFrOgZ ;) 12:13
SmootherFrOgZ ls 12:14
spot hansg: i had no todo items for today, so the floor is open to any topics people might have 12:15
rdieter abadger1999: ah, I had almost forgotten about that. iirc, mclassen kinda wanted the the .desktop file --vendor recommendations changed to *not* recommend using --vendor=fedora 12:15
tibbs We also need to discuss the ACL situation on the wiki 12:15
abadger1999 Yeah, and to adjust all existing packages similarly. 12:15
spot rdieter: realistically, shouldn't we work with upstream to nuke vendor out of that spec? 12:15
hansg Well, if were doing free discussion I'm currently involved in a discussion with some opensuse people on synchronizing our guidelines 12:15
rdieter it's just a recommendation (upstream at that), but many reviewers seem to consider it a MUST item. 12:15
tibbs abadger1999: But we can't change existing packages without breaking things for users, if I understand correctly. 12:16
rdieter spot: yep, and educate reviewers that it's not a blocker 12:16
hansg We are in the process of setting up a mailinglist for this 12:16
spot hansg: nice. 12:16
abadger1999 Did it get stuck b/c mclassen was going to come up with ways to fix the existing package situation but didn't get back to the list with that? 12:16
* rdieter isn't sure where the discussion trailed off, honestly. 12:16
abadger1999 hansg: Nice. Is this more special purpose than distributions-list? 12:17
spot rdieter: would you be willing to revive it with him? :) 12:17
abadger1999 I now f13 was trying to do some synchronizing there. 12:17
rdieter spot: sure. 12:17
abadger1999 I'd love to drop vendor if it didn't hurt users. 12:17
spot abadger1999: agreed 12:17
hansg interesting with regards to the discussions so far is that we quickly focussed on differences in %pre / %post scripts, and from there to how we would like to see rpm enhanced todo things like run gtk-update-icon-cache once at the end of the transaction 12:18
f13 hansg: using the distributions list for this would be best I think. 12:18
tibbs hansg: I don't think anyone would argue that getting rpm to take care of lcdonfig and icon caches is a bad thing. 12:18
hansg abadger1999, f13, we are talking a lot of rpm related stuff, so our plan was to set up an rpm-packaging list somewhere ( for example) and then invite people from the fedora and opensuse packaging lists and also for example the mandriva and pld devel lists. 12:19
tibbs But that's more an issue for the rpm folks at this stage. Do we even know if they have interest in doing that? 12:19
spot tibbs: can't hurt for someone to ask. 12:19
spot hansg: you're the closest to this atm, willing to take this to the rpm devel mailing list? 12:19
spot (this, being the rpm enhancements) 12:20
rdieter I think most of it is just getting %pre/post trans(un) to work, sanely. 12:20
hansg tibbs, spot, our (opensuse people and mine) idea is to write a draft how it would work (seen from the .spec file and what would happen when installed) and then when we have an idea how this would look from the outside which is seen as good by both the suse people and us take it to panu 12:20
spot hansg: ok, thats fair enough. 12:21
tibbs Too bad we don't have panu around. 12:21
spot tibbs: yep. 12:21
spot ok, lets talk about ACLs in the wiki. 12:21
rdieter panu has commented in the past that he's interested in helping make that (kind of) stuff work. 12:21
tibbs The wiki folks are grumbling that we shouldn't have any acls at all. 12:22
spot yeah, well, they can grumble. 12:22
tibbs They're a bit more difficult to manage than they used to be. 12:22
tibbs And they want restricted content moved off of the wiki entirely. 12:22
rdieter must... not... relinquish... power. (wait, did I say that out loud?) 12:22
spot Honestly, i think we need the ACLs to prevent people from writing arbitrary guidelines which are then enforced blindly by others. 12:22
spot The wiki engine makes it easy to structure the guidelines without say, learning TeX 12:23
f13 hansg: well, distros also has PLD on it, and %post type tasks aren't just rpm specific, other packaging tools make use of them. I would just hate to see further splintering off of cross distro communication. 12:23
tibbs Our options are to handle reverts when necessary, to ask for some kind of moderation capacity, or to just ignore the requests for getting rid of acls. 12:23
spot it also keeps this information centralized. 12:23
spot tibbs: afaik, you can't put a watch on Packaging/* 12:23
tibbs Actually, you can't watch regexps in mediawiki as far as I know. 12:24
spot so we can't effectively prevent someone from adding Packaging/RealJava 12:24
spot (where RealJava is new) 12:24
spot nor would we be aware of it until damage is done 12:24
tibbs Unfortunately that's the case. 12:24
rdieter Packaging/Mp3 12:24
spot likely? eh, i don't know. 12:24
spot but I could see some rather... um... opinionated folks abusing. 12:25
spot *cough* 12:25
hansg f13, well since the distributions list is low trafic sofar I guess we could use that and start a new list when the dpkg users start grumbling :) 12:25
f13 nod 12:25
abadger1999 If we could moderate (anyone can add to talk pages but only moderators can change the actual page) that would work for me. 12:25
spot abadger1999: assuming that worked for the entire Packaging/ section 12:26
hansg abadger1999, moderating +1 12:26
tibbs I don't know what the answer is. I would have thought that the justification for ACLs on those pages would be obvious. 12:26
spot i dont have any problem with people editing on the talk pages 12:26
spot but we need to lock down (moderate, acl, whatever) the actual pages in Packaging 12:26
spot and prevent new pages from being created outside of this committee 12:27
tibbs I don't really see that the wiki is the wrong tool for this. 12:27
spot tibbs: neither do i. 12:27
tibbs Certainly for the kind of stuff I do at every meeting, I don't want to have to learn docbook. 12:27
spot tibbs: if anything, i think this might be a place for us to improve the mediawiki acl code if it is so unbearable. 12:28
spot one has to assume that wikipedia has gotten through this issue. :) 12:28
spot is anyone in disagreement here? 12:29
jeremy spot: wikipedia just has an army of people that watch changes and then admins lock pages that get into "wars" 12:29
jeremy (fwiw) 12:29
mmcgrath Seriously guys, if you have highly controlled content thats important it goes through revisions and can't just be edited by everyone follow a docs process. 12:29
spot mmcgrath: i think that we generally disagree with that., 12:30
mmcgrath yeah, because it adds process and is inconvenient. 12:30
mmcgrath but think about it from the point of view of another group. 12:30
spot honestly, we probably have too much process involved with guidelines as is 12:30
mmcgrath If that content isn't supposed to be open to everyone the wiki is a poor choice. If its so important that it can't be edited by people why not put it somewhere where it can be properly controlled, translated, etc? 12:31
spot if people had to follow a docs process to submit a guideline, then approve it, then take it to life? 12:31
mmcgrath Why wouldn't you put it at ? 12:31
spot mmcgrath: because its a living document, not a one time revision drop 12:31
spot its just controlled 12:31
hansg OT: talking about my discussions with opensuse, here is the plan / dream I have which I've started my discussion with them with: 12:31
spot it can (and is edited) by people. just not by _ALL_ people. 12:32
mmcgrath Its just that as far as the wiki goes no one else is doing that. They either revert a change they don't want to have done. 12:32
mmcgrath or they don't put it there at all. 12:32
spot mmcgrath: Licensing has to do that. 12:32
f13 pardon, would it not be enough to be able to send notifications of all wiki edits to the Packaging/ space to say the packaging list? 12:32
spot Legal/* has to do that 12:32
rdieter is guidelines translations really something to be concerned about? (if it is, then maybe a change is warranted). 12:32
mmcgrath then it shouldn't be there. 12:32
mmcgrath it should be somewhere it can be properly controlled. 12:32
spot mmcgrath: i disagree with you 12:32
* mmcgrath understands this. 12:32
hansg I wonder what the FPC thinks of this esp of step 1b (which IMHO is a necessary evil) 12:32
spot i think the wiki is an excellent mechanism for delivering and maintaining this content 12:32
spot and also for people to suggest new content 12:33
rdieter hansg: necessary evil +1 12:33
spot (if anything, the talk pages make this even better) 12:33
mmcgrath Its nothing personal but your packaging stuff just isn't _that_ special compared to the rest of the content on the wiki is all. 12:34
mmcgrath the legal stuff, yes, and again probably shouldn't be on the wiki at all. 12:35
spot the rest of the content on the wiki doesn't define what can and cannot be done in Fedora. 12:35
rdieter mmcgrath: re "properly controlled" content, are you suggesting that our wiki is not suited to that? 12:35
mmcgrath spot: sure it does. 12:35
mmcgrath I mean, there's more to fedora then packaging. 12:35
mmcgrath granted, its the flagship stuff but whatever. You guys have the tool do as you will with it. 12:35
spot mmcgrath: these are the fundamental rules of the road here. 12:35
mmcgrath spot: sort of. 12:36
mmcgrath spot: not for me, art, docs, ambassadors, l10n, etc. 12:36
tibbs I don't recall hearing these arguments when we were using moin. Are we hearing them now because ACLs aren't part of the page text? 12:36
f13 mmcgrath: with the wiki as is, do we have a way of actively monitoring every new page that would be created under Packaging/ ? 12:36
mmcgrath tibbs: no one asked me when the acl's were implemented in Moin. 12:36
spot mmcgrath: they don't have rules in the same context that we do 12:36
mmcgrath f13: we have an extension for that yes, but I don't remember if its implemented and stuff. 12:36
spot if i add art to the wiki, it doesn't automatically become accepted as the new art for Fedora. 12:37
spot if i add an event to the ambassadors table, it doesn't mean Fedora will be there. 12:37
f13 mmcgrath: ok, /if/ we had that, /then/ we'd at least have the ability to notice new pages created and edits done that shouldn't be. 12:37
f13 mmcgrath: until then, we don't. 12:37
mmcgrath and if I create /wiki/PackagingGudelinesForFedora, that does become the new method for packaging? 12:37
spot if someone adds a list of things for say, oh, i don't know, java packaging... 12:37
f13 mmcgrath: If it was linked to from PackageMaintainers, perhaps yes. 12:38
mmcgrath sorry guys, but we have a process for creating official managed content. Other teams use it with great success. 12:38
spot mmcgrath: nope, because we say that Packaging/ is where the rules live. 12:38
mmcgrath Its totally fine if you don't want to use it but won't (and don't have to) convince me of it. 12:38
spot and we have for several YEARS Now 12:38
f13 mmcgrath: if you created /wiki/Packaging/Silverlight you've suddenly created live and "legal" guidelines. 12:38
mmcgrath f13: I can. 12:38
mmcgrath so can lots of wiki admins. 12:38
mmcgrath so can anyone in sysadmin-web. 12:38
spot mmcgrath: you could have done so with the old wiki too 12:39
mmcgrath yep 12:39
spot we trust our admins not to be asshats. 12:39
mmcgrath and it was the wrong tool to use then as we.. 12:39
spot if you're saying we can't... 12:39
mmcgrath er well 12:39
mmcgrath I'm not saying you can't. 12:39
spot i'm not worried about our admins 12:39
f13 mmcgrath: we could also have watches on entire namespaces with the old wiki 12:39
f13 mmcgrath: so that if you were an asshat, we could catch that 12:39
spot i am worried about joe random who decides our guidelines are crap and "fixes" them for me. 12:39
f13 mmcgrath: but you're saying now that A) we can't do ACLs, and B) we can't watch an entire namespace. Where does that leave us? 12:39
spot or adds his own guidelines. 12:40
mmcgrath f13: I could implement that tonight but that wouldn't drop the acl requirement I suspect for the rest of you guys. 12:40
spot mmcgrath: why are you opposed to acls? 12:40
f13 spot: /IF/ we had namespace watching capability, and had those diffs delivered to the packaging-list or packaging-commits-list, would that suffice? 12:40
spot because they are hard to implement? 12:40
abadger1999 hansg: How many virtual provides are we talking? A few or one for every current devel package? 12:40
mmcgrath f13: I'm saying ACL's are a huge pain in the ass, they were with moin as well, I'm saying if you google for reaons not to use ACLs in wiki's you'll find tons of examples, I'm saying we have proccesses in place that lots of people use for official special content. 12:40
mmcgrath I'm also saying its your choice if you chose to ignore all of that and do it anyway. 12:40
* rdieter thinks we should at least consider mmcgrath's suggestion, long-term anyway. 12:41
spot i think if we move to a "watch people make changes at will" approach, we've circumvented this committee. 12:41
f13 mmcgrath: in our opinion, managing the content in the same place we manage all the other content outweighs the conceptual issues of "locking 12:41
spot i think we invite revert wars. 12:41
f13 " people out of wiki pages. 12:41
hansg abadger1999, I have no idea, not one for each devel package, but I think atleast one for half of all the devel packages think things like (fake example, dunno if this is real) libxml2-devel versus libxml-devel, caps differences, etc. 12:42
f13 spot: are you willing to give it a trial? 12:42
mmcgrath spot: we have an elected comittee in epel, with rules. Never once do I recall a revert war. People respect the decisions of the sig. 12:42
spot mmcgrath: people often disagree pretty vocally with our decisions 12:42
spot f13: honestly? not really. 12:42
mmcgrath sorry guys, I've got to get back to cabling. You've got the tools, really, feel free to use them as you will. 12:43
spot we have several years of evidence that ACLs works well for us. 12:43
abadger1999 hansg: Hmm.. If you get a ballpark figure we should run it by skvidal. vitrual provides aren't entirely free. 12:43
abadger1999 rdieter: +1 12:43
mmcgrath sort of, you have years of evidence that your pages haven't been altered... whether or not thats the acl's or not... 12:43
spot mmcgrath: no, i get emails since my name is on most of them 12:43
hansg abadger1999, true (not being entirely free) 12:44
spot when people try to make changes and cannot 12:44
spot 95% of the time, people are trying to add things they think are "obviously correct", which are not. 12:44
spot often times, these items are politically motivated 12:44
spot or things like making dist tags mandatory 12:45
* spot feels like he's talking to himself here 12:45
* hansg can't help getting the feeling he is watching the spot & mmcgrath show, which seems to be family of the Tom en Jerry show 12:45
tibbs I just don't get the moral argument that "wikis should be free". If the ACL arrangement is a pain in the rear, then perhaps we need to figure out how to fix the software. 12:46
spot tibbs: yeah, i really don't get that one either. 12:47
spot tibbs: it has a login/account mechanism for a reason. 12:47
rdieter I thought we were only talking about "acls are a pain" issues. 12:47
spot rdieter: well, we're really hearing "acls are hard, why can't you just use docbook" 12:48
rdieter could be cool, to have translated, nice-looking, potentially printed/published guidelines. 12:48
spot rdieter: sadly, they'd be about as current and relevant as most printed books on Fedora. 12:49
rdieter ha, true. 12:49
spot thats really the point, the concept of the living online document 12:49
spot the Fedora docs are almost entirely point release driven 12:50
hansg FWIW, I believe that a locked down (using ACL)'s wiki, as we have is much better then using something like docbook 12:50
spot they're not living documents, per se 12:50
spot a much more interesting idea to me is if we can un-ACL the talk pages 12:50
spot as there is no merit in locking them down 12:50
tibbs Yes, that could be quite useful. 12:50
hansg +1 to not locking down the talk pages 12:51
spot okay, any other items for discussion? 12:53
spot aside from buying mr. mcgrath a beer at fudcon for having to suffer with our odd wiki needs? :) 12:53
hansg Well abadger1999 and rdieter have alreayd responded, but if possible I would like a quick opinion from the others to on this: 12:53
hansg OT: talking about my discussions with opensuse, here is the plan / dream I have which I've started my discussion with them with: 12:54
hansg I wonder what the FPC thinks of this esp of step 1b (which IMHO is a necessary evil) 12:54
spot i'm not really sold on 1b 12:54
tibbs Me neither. 12:54
spot thats a lot of extra provides to slow down dependency ops 12:54
tibbs How do they name their -devel packages? 12:55
spot i think it would be more interesting to try to standardize naming between the two as a onetime merge 12:55
mmcgrath you guys have normal cms needs, just bad wiki needs :) I haven't touched the talk stuff but IIRC that should be pretty easy to open up if its not already open. 12:55
hansg If we want to make sharing specfiles possible without to much %if stuff, 1b is a necessary evil I'm afraid 12:55
mmcgrath I also don't know how watching talk stuff goes, anyone know if notifications go out about that? 12:55
rdieter spot:most definitely, long term, but what about short-term? 12:55
spot mmcgrath: if you need me to open a ticket for that, i can. 12:55
tibbs Again: how do they name their -devel packages? 12:55
tibbs Are the differences regular so that we can just macro-ize the devel dependencies? 12:56
mmcgrath spot: please do, ricky or I will get to it pretty soon. I'm working with galgoci to find 16 free ports :) 12:56
spot rdieter: well, if we're collaborating, we can consult the other before new packages go in 12:56
rdieter sure, and existing packages with naming differences? 12:56
hansg same as we, but there are differences think thinks like libxml versus libxml2, sometimes we have choosen to put a version number in the %name, sometimes they have when things were / are parallel installable 12:56
rdieter just live with the pain? 12:56
spot what do we gain by providing the OpenSUSE name? 12:57
hansg I'm not sure how large the list of affected packages is, I think this discussion is easier to have when we have some numbers 12:57
rdieter being compatible pkgname-wise. 12:57
spot hansg: that would be worthwhile to see 12:57
spot if this is 30, 50 provides, maybe. 12:57
spot 500, 1000? nah. 12:57
hansg spot, people can take an opensuse srpm, do an rpmbuild and have an rpm 12:58
spot hansg: maybe, i'd wager that things will never be that simple for anything complicated. 12:58
hansg spot, well there is willingness on the opensuse side to strife towards this 12:59
spot hansg: we'd need to also look into matching up configuration options 12:59
spot if we're serious about that as a goal 12:59
hansg I spend quite a lot of time sharing fixes with other distro's, for things like a simple game which needs just SDL, it would be a blessing to have a single srpm for all rpm based distros 13:00
f13! 13:00
* f13 hides 13:00
spot hansg: if you can generate some numbers on how many provides/name changes we'd be looking at... 13:00
hansg spot, yes we need numbers so lets leave it at that for now 13:01
spot hansg: okay. 13:01
spot we're right at one hour now, so i think i will close this meeting 13:01
spot any objections? 13:01
tibbs Did we actually resolve anything? 13:01
hansg f13, is available :) 13:01
spot tibbs: no, but we didn't actually have anything on the agenda. :) 13:02
tibbs Going to be a short summary, then. 13:02
spot tibbs: "spot and mmcgrath argued. spot agreed to buy mmcgrath a beer." 13:02
spot ok folks, thanks, we'll see you in two weeks 13:03

Generated by 2.6 by Marius Gedminas - find it at!