17:00:16 #startmeeting FESCo meeting 20091030 17:00:16 Meeting started Fri Oct 30 17:00:16 2009 UTC. The chair is jds2001. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:16 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:21 #chair dgilmore dwmw2 notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler 17:00:21 Current chairs: Kevin_Kofler dgilmore dwmw2 j-rod jds2001 nirik notting sharkcz skvidal 17:00:25 * j-rod here 17:00:27 * nirik is here. 17:00:28 hi 17:00:29 fish 17:00:30 * skvidal is here 17:00:34 #meetingname fesco 17:00:34 The meeting name has been set to 'fesco' 17:00:36 * sharkcz is here 17:00:37 * notting is here, although generally behind on things 17:00:41 j-rod: you looking to set a record :) 17:00:45 * dwmw2 is just generally backward 17:00:54 nirik: what does that do? 17:01:02 Present. 17:01:20 jds2001: it uses it in the filenames if set. If not it defaults to channel... 17:01:37 #topic quick DST question 17:01:42 so it's easier for folks looking at the index to see which is the fesco meeting, etc. 17:01:49 so the US ends DST this weekend 17:01:53 nirik: makes sense 17:02:03 jds2001: personal record for consecutive meetings attended with an on-time arrival? :) 17:02:03 do we want to move the time, or not? 17:02:26 I'd prefer not to. Keep it at 17:00 GMT. 17:02:49 yeah, im leaning the same, except i get no lunch in that case :D 17:02:52 whatevs. makes friday lunch plans impossible either way 17:03:04 j-rod: exactly 17:03:08 * skvidal has no opinion 17:03:16 meeting at 6-7pm on a Friday night is antisocial :) 17:03:17 on this subject 17:03:17 :) 17:03:18 17:00 UTC is probably better here. 17:03:21 * nirik doesn't care either. does it mess with any other meetings? 17:03:24 * sharkcz prefers 17:00 GMT 17:03:45 dwmw2: what, you have a social life?! ;-) 17:03:48 That way my mother has to wait an hour less for me to have time for dinner. ;-) 17:03:53 #agreed meeting will stay 1700UTC 17:03:58 Kevin_Kofler: :) 17:04:10 XulWork: nah, this is just my latest excuse for not having one :) 17:04:16 hehe 17:04:44 #topic fluidsynth and PA 17:04:48 .fesco 265 17:04:50 jds2001: #265 (oget refuses to enable fluidsynth's PulseAudio backend) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/265 17:05:06 oget: you around? 17:05:33 * jds2001 generally feels that FESCo is not in the business of micro-managing maintainers. 17:05:48 +1 17:05:48 not in the business 17:05:48 and more importantly 17:05:49 however, Kevin_Kofler is correct, in that PA is required by everything and it's brother 17:05:55 jds2001: who is? 17:05:57 if anyone brings it to fesco for me to change a setting in yum 17:06:01 I'm going to come out swinging 17:06:23 I think we really ought to make sure common distro features are consistently supported. 17:06:32 Do we want Fedora to become a hodgepodge of incompatible things? 17:06:43 What's the purpose of a distribution if there's no integration? 17:06:46 this gets back to our target audience 17:06:52 as such was defined recently 17:06:56 This is not micromanagement, this is macromanagement of a common distro feature. 17:07:02 I'd like us to ask oget for his reasoning, etc. 17:07:03 Kevin_Kofler: I disagree 17:07:13 nirik: +1 17:07:24 is pulseaudio-libs actually required by much? 17:07:28 nirik: See the bug report. 17:07:31 yes 17:07:34 He doesn't want to require pulseaudio-libs. 17:07:39 we used to be able to remove pulseaudio completely, if we wanted functional sound. 17:07:41 kde, gnome, any media player 17:07:44 But you basically can't install Fedora without it anyway. 17:07:49 dwmw2: almost everything related to audio somehow drags it in 17:07:58 the only thing I was aware of that broke that recently was bluez requiring pulse 17:08:05 which I complained about at the time. 17:08:08 Kevin_Kofler: is that it? Is there a bug or any other record of this? 17:08:08 You can remove the main package (unless you need gnome-bluetooth), but not -libs. 17:08:10 dwmw2: requiring the libs does not require the daemon 17:08:19 ah, right 17:08:25 nirik: https://bugzilla.redhat.com/show_bug.cgi?id=500087#c13 17:08:27 Bug 500087: medium, low, ---, green, NEW, Fluidsynth pulseaudio backend not built 17:08:28 you can also just remove the alsa plugin and it never runs. 17:08:57 is fluidsynth much of a common pkg? 17:08:58 (It's linked from the my Trac proposal where I make my case.) 17:09:34 do we really need to muck with folks who have a pkg they maintain that isn't critpath and isn't commonly installed? 17:09:41 much as I despair of pulse, I think he ought to enable the back end. 17:09:53 oh cute. the maintainer said that if PA is required by the guidelines, (not mandated by FESCo, just required somewhere), he will orphan his package 17:10:18 skvidal: isn't that what makes it a coherent distribution rather than a random collection of packages? 17:10:18 notting: gotta love the nuclear option 17:10:33 dwmw2: so if we want coherency we want to have N desktops? 17:10:38 and their different themes? 17:10:50 hm? 17:10:58 We share a look&feel as much as possible! 17:11:06 sorry but pushing political agendas "get rid of pa" should not be done at the cost of the user expirece 17:11:11 okay 17:11:11 In fact we had a flamewar last week over artwork deadlines just because of that. 17:11:12 AGAIN 17:11:20 is fluidsynth all that big of a deal pkg-wise? 17:11:30 am I missing a massive install-base of fluidsynth? 17:11:34 * jds2001 doesn't think so. 17:11:38 no. Let him orphan it :) 17:11:39 yeah, not widely used 17:11:47 I don't know but I don't really care 17:11:48 it's a frelling MIDI INPUT handler 17:11:50 christ 17:12:03 but I think the PA backend should be enabled in it 17:12:06 Just because not everyone uses it doesn't mean it shouldn't be built with the integration features upstream provides! 17:12:08 well, what are our options here? a) do nothing, let folks using pulse not use this. b) tell him to add those/do it and if need be he can orphan his package c) ask nicely with sugar for him to do so, d) something else? 17:12:17 better to drop it completely than to have it gratuitously not fit into the distribution's chosen model for sound stuff 17:12:17 * jds2001 too, but I don't think we can/should mandate that. 17:12:21 Proposal: leave oget the and fluidsynth the hell alone out in the far reaches of the pkging leafnode space 17:12:34 dwmw2: we have TONNES of crap in the distro that don't really fit anywhere 17:12:35 * jds2001 feels option c is correct. 17:12:43 they just don't really NOT fit, either. 17:12:45 I'm for b). 17:12:54 I fear c will do nothing. Since he hates pulse and calls it torture. 17:12:57 skvidal: but this one is _gratuitously_ so. 17:13:03 gratuitously? 17:13:07 e) ditch pulse completely :) 17:13:07 c) will be as useless as a). 17:13:10 to the 5 people who use midis? 17:13:17 skvidal: there's no good reason for him not to enable the pulse back end. 17:13:22 And I have no idea what "other option" d) would be. 17:13:23 I'll cry a single dramatic tear 17:13:23 skvidal: given he describes the use of the default system as inflicting torture on users? 17:13:23 hence 'gratuitously' 17:13:24 this seems like a case of a maintainer putting their own feelings over the good of their users... which seems a poor positition for a maintainer to me. 17:13:33 dwmw2: Indeed. 17:13:33 notting: so we're all being overly dramatic? 17:13:38 dwmw2: s/no good/no/ 17:13:39 skvidal: we? 17:13:42 yes 17:13:46 nirik: Right. 17:13:48 he is being dramatic about pulse 17:13:55 and we're being dramatic about the importance of this pkg 17:13:58 b/c it REALLY isn't 17:14:05 If he hates PA, he should leave Fedora, entirely. 17:14:09 It's our default sound solution. 17:14:14 yeah lets say I don't like $hwvendor so I patch my packages to not run on it 17:14:19 will fesco be ok with that? 17:14:23 I suppose no 17:14:29 Kevin_Kofler: yes - let's draw a line in the sand! 17:14:35 drago01: Good point. 17:14:42 drago01: do you really think banning a hw vendor is the same 17:14:45 I can patch kdelibs to refuse to run on nvidia hardware tomorrow. :-p 17:14:51 as ONE PKG that is a midi handler? 17:15:06 Kevin_Kofler: Poulsbo, please :) 17:15:12 I'd say the impact is MANY orders of magnitude different 17:15:19 skvidal: it is pushing some agenda at the cost of the users (but yeah it isn't really apples vs apples but you should get the point) 17:15:22 so let's have the appropriate level of drama 17:15:29 skvidal: So if ONE PACKAGE is patched to boycott a hardware vendor, that's OK? 17:15:32 drago01: I push an agenda too in yum 17:15:33 I agree with skvidal that it's not really worth getting worked up about 17:15:41 the package is mostly irrelevant 17:15:44 * jds2001 too 17:15:44 That "one package" argument makes no sense. 17:15:46 but the request is perfectly reasonalbe 17:15:48 drago01: it's the 'when shit breaks the user should know' agenda 17:15:54 except to the extent that it sets a precedent. 17:16:03 dwmw2: but it doesn't set a precedent 17:16:04 skvidal: if we're trying to promote a 'just works' philosophy, how does letting maintainers remove the just-works-by-default option due to personal irrational prejudices make sense? 17:16:06 Indeed, it sets a precedent. 17:16:07 here I'll phrase it right 17:16:09 skvidal: no that is how your software is designed 17:16:22 and "zomg, it'll pull in pulseaudio-libs" hardly seems justification for rejecting a reasonable request 17:16:22 drago01: but I'm PUSHING MY AGENDA THROUGH IT :) 17:16:28 does anyone actually want to _use_ this package with pulse, or is it just a theoretical objection to oget's package? 17:16:28 dwmw2: we take these on individual case basis....... 17:16:35 dwmw2: ding! 17:16:36 dwmw2: I do. 17:16:39 skvidal: he maintains 62 packages... is it ok for him to remove any pulse support from all of them then? or does it matter what they are? 17:16:41 and if someone _does_, are they volunteering to take over the package maintenance? 17:16:52 nirik: how about we cross that bridge when/if we come to it 17:16:58 nirik: instead of a kneejerk reaction 17:17:07 http://markmail.org/message/bovdqb7na3zor2ck - without comment. 17:17:11 * nirik checks his knee. Nope, not jerking. ;) 17:17:43 mjg59: .... 17:17:43 * dgilmore is here 17:17:54 right 17:18:02 so oget is a 15 yr old maturity-wise 17:18:09 and sees the world as full of drama 17:18:11 great 17:18:21 let's deal with this problem when it is ACTUALLY a problem 17:18:36 isn't it already with users of that package? 17:18:45 the package is a leafnode 17:18:47 NOTHING requires 17:18:48 it 17:18:53 so someone has to be working HARD 17:18:54 skvidal: we should deal with issues before they become a real problem ;) 17:18:59 Kevin_Kofler: are you willing to maintain this package? 17:19:01 but users of it have made a reasonable request 17:19:11 j-rod: which bug report is that? 17:19:16 * dgilmore thinks that its not ok to wholesale disable pulse support, but its ok to have an option to run without if the user choses 17:19:16 dwmw2: Yes. 17:19:22 https://bugzilla.redhat.com/show_bug.cgi?id=500087#c13 17:19:24 Bug 500087: medium, low, ---, green, NEW, Fluidsynth pulseaudio backend not built 17:19:26 But he's threatening to orphan everything that depends on it too. :-/ 17:19:29 yeah, that one 17:19:31 And I have no idea how much that is. 17:19:35 skvidal: 500087. the original request was from a users, not from kkofler 17:19:42 Kevin_Kofler: nothing, according to skvidal 17:19:45 dgilmore: building the backend does exactly that (it will work with pulse or without) 17:19:45 notting: Right. 17:19:58 dwmw2: At least qsynth depends on it. 17:19:59 'from a users'. geez, can't type. 17:20:07 oh 17:20:07 You need to check the deps on fluidsynth-libs, not fluidsynth. 17:20:07 so here's my issue 17:20:20 i dont want to set precedent of micromanagement 17:20:39 define "micromanagement" 17:20:40 So there are at least 2 people who are asking for PA support because they want to use it (I do too). 17:20:41 but this particular packaging decision is hair-brained 17:20:44 I don't really think this is micromanagement. This is setting the direction for the distro (pulse) and expecting people to follow it. 17:20:45 and full of drama. 17:20:53 * nirik would normally suggest asking nicely... but I'm not sure that will do much in this case. 17:20:54 I also don't see this as micromanagement. 17:21:08 jds2001: and responding to it is just continuing the drama - and I assure you we'll get more bs from it 17:21:16 nirik: echo "please enable pulse" > /dev/null 17:21:28 of course this isn't really urgent, so we have time to do so if anyone thinks it will do any good. 17:21:39 drago01: Yeah, that's what "asking nicely" will acheive. ^^ 17:21:45 so let's end this at 1730 17:21:45 Would it be micromanagement for FESCO to mandate that packages that implement support for the distribution default sound server enable support for the distribution default sound server? 17:21:46 comment from the sidelines. It appears that one would have to /break/ pulseaudio in order to use this package 17:21:58 how about just asking of Kevin_Kofler can take over maintenance, without oget orphaning other packages in protest. 17:22:06 so in order to use this package, other packages that depend on the alsa pulseaudio plugin would be broken 17:22:18 I don't think that's something the project should condone. 17:22:35 Oxf13: huh? aiui, this particular app cant use pulse 17:22:45 it doesn't actively break it for other users. 17:22:53 yes it does 17:22:54 jds2001: you must remove pulse currently to use it. 17:22:58 Simple software synthesizer using vkeybd and fluidsynth doesn't work unless I 17:23:01 remove alsa-plugins-pulseaudio 17:23:04 so anything that uses pulse will not work on your machine when it's removed. 17:23:11 oh, well that's just not cool. 17:23:20 If something uses direct ALSA or JACK, it takes the device away from PA users. 17:23:25 description from the bug. 17:23:26 * jds2001 is not a huge desktop guy, sorry for my lack of education. 17:23:30 Oxf13: yeah building the pa backend will fix that 17:23:36 right, and the maintainer actively hates pulseaudio and has intentionally crafted his packages to conflict with it 17:23:46 this should not be tolerated 17:23:53 ugh 17:23:59 (direct ALSA without the ALSA PA plugin, but fluidsynth doesn't work with that one, that's why the native backend is needed) 17:24:07 it's one thing to disable a feature you don't want 17:24:10 even if it is orphaned and nobody picks it up it is better than the current state imho 17:24:15 it's a whole other to fuck with features for everyone else 17:24:15 a similar case might be something that has a maintainer that hates NM, and makes their packages not work with it/require you to remove it. 17:24:45 skvidal: so you do get my point (about pushing agendas at the cost of users) 17:24:47 I thought this was only impacting the one leafnode no one uses 17:24:49 drago01: no 17:24:53 drago01: that's not the same thing 17:25:00 if I want to pkg something WHICH ONLY IMPACTS MY PACKAGE 17:25:02 I should be able 17:25:03 to 17:25:14 he wants to pkg something which screws with OTHER people's pkgs as a result 17:25:18 that's different 17:25:24 think of it like this 17:25:24 * jds2001 agrees with skvidal. When it gets for screwing with PA, we can't allow that. 17:25:33 (but only on those machines where people install/want to use this) 17:25:33 if I want to mow my yard in some way 17:25:37 so a %post rm -rf / in my own package is fine ;) 17:25:37 skvidal: That's the whole reason I'm bringing this to arbitration. 17:25:45 Kevin_Kofler: that was not AT ALL clear 17:25:48 skvidal: I think drago01 was trying to say if he added a apckage that required the removal of NM to work 17:26:01 Oxf13: again - that was not, AT ALL clear from the discussion 17:26:11 Oxf13: thank you for making it clear 17:26:17 * jds2001 is also just receiving this education. 17:26:19 not from the discussion no, but a 10 second look at the bug turned it up 17:26:19 skvidal: well that was what I was trying to say 17:26:39 not sure it's *completely* intentional. it seems that it tries to use direct ALSA, but doesn't work with that redirection through PA. that's sort of an upstream issue. but it can be fixed by enabling the PA backend in the build, so we really should just do that 17:26:55 so, back to our options... 17:27:04 Oxf13: forgive me for misunderstanding then - it seems like I wasn't the only one who misunderstood 17:27:25 proposal: someone asks nicely. if that doesn't work, orphan package for another maintainer? 17:27:26 so let's just vote on the options presented before, taking into account the new information. 17:27:31 notting: right, 17:27:35 Proposal: Kevin_Kofler volunteers to take over maintenance of the package without FESCo being heavy-handed about it. If oget doesn't agree to that, we'll think of something else. 17:27:37 nirik: +1 17:27:58 dwmw2: +1 to that too. 17:28:10 +1 to either 17:28:13 since asking nicely is likely to be equivalent to pissing in the wind. 17:28:20 * nirik doesn't know if asking nicely will make things worse or not... but I tend to think we should try. 17:28:21 +1 to either too 17:28:29 +1 sure 17:28:42 in the grand scheme of things, PA-libs is a 2MB package without exotic deps; it doesn't make it actually require the daemon 17:28:43 so what are we agreeing to for the minutes? :D 17:29:03 yeah, I'm slightly confused what we're agreeing to 17:29:07 jds2001: we agreed that you would take care of it and not bother us with it again :) 17:29:11 * dgilmore would pfere that Kevin_Kofler and oget work together on it 17:29:18 skvidal: fat chance :D 17:29:26 How can I work with somebody who just says "no". 17:29:29 -. +? 17:29:30 but if oget wont then Kevin_Kofler taking over is fine. so +1 to dwmw2's proposal 17:29:36 dgilmore: I would prefer that I could mix vingear and baking soda and not have it fizz 17:29:46 Building the subpackage is trivial. 17:29:46 Basically, what *I* agree to, is "the PA backend must be built" 17:30:04 * drago01 prefers that oget just stops acting like a child 17:30:04 "FESCo is of the opinion that individual packages should follow the overall direction set by the project, and that means not actively requiring things like pulseaudio to be disabled. FESCo would like oget to make the requested change, or failing that, perhaps he would consider allowing Kevin to take over maintenance of the package" 17:30:04 skvidal: :) but that cleans your drains 17:30:04 but well.... 17:30:04 Uh, not subpackage, sorry. 17:30:04 The feature. 17:30:04 dgilmore: it does 17:30:06 It can't be a subpackage. 17:30:09 dwmw2: umm - no 17:30:15 Because the backends are static parts of the one fluidsynth shared object. 17:30:17 dwmw2: that seems overly general 17:30:17 It _could_ be a subpackage; just requires a little real maintenance instead of packagemonkeying :) 17:30:21 let's just say 17:30:34 your pkg should not break other features if they are being used 17:30:38 or better yet 17:30:45 dear oget: this is how it has to be 17:30:48 Enabling the feature is just the question of adding a BR and maybe a configure switch in any case. 17:30:50 Kevin_Kofler: do you agree to take over as maintainer if oget refuses to add the feature? 17:30:55 and we address any others on a case by case basis 17:30:58 jds2001: Yes. 17:31:23 skvidal: case by case would be "micromanagement" 17:31:35 a generall rule should fix that once and for all 17:31:35 so, Kevin_Kofler will ask one last time and failing that will take over and make it so? 17:31:48 a general rule saying your pkg must be compliant with the vague 'features of the distro' is worse 17:31:57 nirik: that sounds round to me 17:32:01 #agreed PA backend for fluidsynth must be built. If the current maintainer refuses, Kevin_Kofler will take over as maintainer. 17:32:09 skvidal: s/must/should try/ 17:32:10 +1 to that. 17:32:12 skvidal: well add another rule that requires common sense 17:32:14 drago01: a general rule is NOT going to fix it - it's going to make us have more of these arguments 17:32:14 done 17:32:15 sound correct? 17:32:24 drago01: common sense is frequently neither 17:32:26 worksforme 17:32:37 +1 here. Hopefully it will all work out and we can all just get along. ;) 17:32:38 awesome. 17:32:39 jds2001: +1 17:32:40 skvidal: (wasn't serious about the last one) 17:33:08 Yeah, sounds correct, can we move on now? 17:33:16 yeppers 17:33:17 +1 17:33:34 #topic legally objectionable, binary and non-free items 17:33:40 .fesco 264 17:33:42 jds2001: #264 (Prohibit packages which require non-free, legally unacceptable, or binary only content to be functional) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/264 17:33:54 I'm still confused by the language here. 17:34:03 * jds2001 gets the intent 17:34:12 isn't this already a guideline? 17:34:20 XulWork: No. 17:34:28 how about the items at: http://www.redhat.com/archives/fedora-devel-list/2009-October/msg00630.html how would they be affected? 17:34:32 We just ban the evil content itself, not stuff which doesn't work without it. 17:34:35 nothing currently in the distro is affected? 17:34:42 did we ever find out what the group is who wanted to put something in? 17:34:44 nirik: no there would be things affected. 17:34:47 The problem is that there's some contention about what "doesn't work without" the bad code. 17:34:54 Oxf13: ok, do we have a list of such? 17:35:24 thats silly, i can take my dvd player which requires libdvdcss, brand it as Hello World which doesnt need libdvdcss and its acceptable 17:35:31 er, didn't you just post a list of things that would be affected? 17:35:41 can someone define "code dependency" ? 17:35:46 skvidal: does it matter? 17:35:52 libdvdread is perfectly functional without libdvdcss, it just doesn't support encrypted DVDs. 17:35:57 a dvd player doesn't require libdvdcss. ∃ unencrypted DVDs. 17:35:58 Oxf13: not that I know of. It was a list of things from a thread a while back that I posted. 17:35:59 But it can read an unencrypted DVD just fine. 17:36:02 it does, however, require mpeg support :) 17:36:11 jds2001: no - I'm just curious about it 17:36:20 Like one which has been previously un-CSSed and burned without encryption. ;-) 17:36:20 i was just using a hypothetical example 17:36:40 if i did have a software package which required libdvdcss, i could just rebrand it as a hello world app to get it into fedora 17:36:42 Could have sworn there was something in the Electronics Lab that would be hit by this 17:36:52 libvdpau is fine - it does not require non-free stuff in the "runtime operating environment" 17:37:00 Oxf13: there is 17:37:09 it can be used with remote non-free stuff 17:37:14 jds2001: I think in this example it's really just a lame excuse. 17:37:15 so this would affect all the mpd frontends? 17:37:21 no, those are just clients 17:37:24 to a remote server 17:37:25 Who in their right mind would use accelerated video over X11 forwarding??? 17:37:29 or those are ok, because they are just calling to remote? 17:38:24 The vast majority of uses (like 99.9+%) will be with proprietary drivers on the machine itself. :-/ 17:38:30 at this time, yes, probably 17:38:34 but so what. that's not relevant. 17:38:53 we've already been over this 17:38:55 But clients for remote servers are indeed tolerable according to that proposed guideline (or at least that's spot's intent). 17:39:06 spot: so, what's the impetus package/review? 17:39:53 so this doesn't affect anything currently in I guess... but I'm still not sure what "code dependency" is... linking ? calling locally a command? 17:39:59 I think that's a quite dangerous road to be on, but I also don't propose we rip off integration with web services from all the apps out there! 17:40:27 no, i think it's like the realplayer download thing (at least on windows) - you install some small thing 17:40:38 and it downloads some other huge blob 17:41:02 there are a number of installers like that, and i suspect this is one of those type of things. 17:41:10 which it links to/calls... ie, code, not content. 17:41:20 right 17:41:48 Hmmm, Codeina fits that definition, really. 17:42:11 not really, codeina does nothing by itself. 17:42:21 Isn't that kinda the point? 17:42:26 Kevin_Kofler: a) it's gone, b) it doesn't require downloaded things to be usefull. 17:42:53 nirik: you beat me :) 17:42:53 it just directs you how to download things. 17:42:55 * nirik finishes re-reading the ticket and looking at some other things... I think I am +1 on this now. 17:43:04 if we had a music player that wasn't useful unless it went and downloaded codec packs from fluendo, that would be not okay 17:43:37 *that* is the sort of thing we're trying to prevent here, no? 17:43:41 j-rod: there is something in the electronics lab that needs propietary something to work 17:43:46 if we have a music player that *offers* to go download codecs from fluendo, but could work with gstreamer-plugins-[bad,ugly], that's cool. 17:43:55 kind of. Although if it required stuff which is in rpmfusion, I'd be OK with that :) 17:44:03 we let it in because there is a free and open in development 17:44:12 dgilmore: No, we voted not to allow it. 17:44:23 hm, I vaguely recall that discussion, but not much of the details... 17:44:26 notting: package is not currently under review 17:44:28 Kevin_Kofler: i thought we ended up saying yes 17:44:34 dgilmore: that was free content for non free software (with free in development) 17:44:38 im happy if im wrong 17:44:46 nirik: ahh right 17:45:03 we voted to wait until their was a free software that could use it, IIRC. 17:45:14 dgilmore: and even then, we said come back with some free software that can use it.\ 17:45:14 Now there's some partially working Free SystemVerilog interpreter, so at this point it might be possible to ship that content, or it might become soon. 17:45:27 Kevin_Kofler: that would be good news. 17:45:43 anyhow, shall we vote here? or is there additional discussion? 17:45:46 But the FEL folks certainly know better than me what the state of that stuff is. 17:46:03 +1 to the latest draft 17:46:28 +1 here as well. 17:46:29 +1 to spot's proposal 17:46:32 +1 17:46:36 +1 17:46:36 given that it doesn't affect anything current, sure, +1 17:46:37 +1 17:46:42 +2 17:46:44 +1 17:46:59 * nirik wonders why jds2001 gets 3 votes. ;) 17:47:00 #agreed spot's proposal is accpeted. 17:47:03 lol 17:47:03 (It might even not be strict enough, but it's definitely an improvement over the status quo.) 17:47:08 +1 it clears up what we have always said 17:47:28 thanks guys, i think this will clarify things quite a bit 17:47:55 cool, next step is to recurit someone to write this up on the wiki 17:47:59 spot: I'd still love to know who was gaming the system :) 17:48:10 skvidal: ask me in toronto over alcohol. 17:48:18