17:00:16 <jds2001> #startmeeting FESCo meeting 20091030
17:00:16 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:21 <jds2001> #chair dgilmore dwmw2 notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler
17:00:21 <zodbot> 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 <skvidal> hi
17:00:29 <dwmw2> fish
17:00:30 * skvidal is here
17:00:34 <nirik> #meetingname fesco
17:00:34 <zodbot> 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 <jds2001> j-rod: you looking to set a record :)
17:00:45 * dwmw2 is just generally backward
17:00:54 <jds2001> nirik: what does that do?
17:01:02 <Kevin_Kofler> Present.
17:01:20 <nirik> jds2001: it uses it in the filenames if set. If not it defaults to channel...
17:01:37 <jds2001> #topic quick DST question
17:01:42 <nirik> so it's easier for folks looking at the index to see which is the fesco meeting, etc.
17:01:49 <jds2001> so the US ends DST this weekend
17:01:53 <jds2001> nirik: makes sense
17:02:03 <j-rod> jds2001: personal record for consecutive meetings attended with an on-time arrival? :)
17:02:03 <jds2001> do we want to move the time, or not?
17:02:26 <dwmw2> I'd prefer not to. Keep it at 17:00 GMT.
17:02:49 <jds2001> yeah, im leaning the same, except i get no lunch in that case :D
17:02:52 <j-rod> whatevs. makes friday lunch plans impossible either way
17:03:04 <skvidal> j-rod: exactly
17:03:08 * skvidal has no opinion
17:03:16 <dwmw2> meeting at 6-7pm on a Friday night is antisocial :)
17:03:17 <skvidal> on this subject
17:03:17 <skvidal> :)
17:03:18 <Kevin_Kofler> 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 <XulWork> dwmw2: what, you have a social life?! ;-)
17:03:48 <Kevin_Kofler> That way my mother has to wait an hour less for me to have time for dinner. ;-)
17:03:53 <jds2001> #agreed meeting will stay 1700UTC
17:03:58 <jds2001> Kevin_Kofler: :)
17:04:10 <dwmw2> XulWork: nah, this is just my latest excuse for not having one :)
17:04:16 <XulWork> hehe
17:04:44 <jds2001> #topic fluidsynth and PA
17:04:48 <jds2001> .fesco 265
17:04:50 <zodbot> jds2001: #265 (oget refuses to enable fluidsynth's PulseAudio backend) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/265
17:05:06 <jds2001> oget: you around?
17:05:33 * jds2001 generally feels that FESCo is not in the business of micro-managing maintainers.
17:05:48 <skvidal> +1
17:05:48 <skvidal> not in the business
17:05:48 <skvidal> and more importantly
17:05:49 <jds2001> however, Kevin_Kofler is correct, in that PA is required by everything and it's brother
17:05:55 <drago01> jds2001: who is?
17:05:57 <skvidal> if anyone brings it to fesco for me to change a setting in yum
17:06:01 <skvidal> I'm going to come out swinging
17:06:23 <Kevin_Kofler> I think we really ought to make sure common distro features are consistently supported.
17:06:32 <Kevin_Kofler> Do we want Fedora to become a hodgepodge of incompatible things?
17:06:43 <Kevin_Kofler> What's the purpose of a distribution if there's no integration?
17:06:46 <jds2001> this gets back to our target audience
17:06:52 <jds2001> as such was defined recently
17:06:56 <Kevin_Kofler> This is not micromanagement, this is macromanagement of a common distro feature.
17:07:02 <nirik> I'd like us to ask oget for his reasoning, etc.
17:07:03 <skvidal> Kevin_Kofler: I disagree
17:07:13 <skvidal> nirik: +1
17:07:24 <dwmw2> is pulseaudio-libs actually required by much?
17:07:28 <Kevin_Kofler> nirik: See the bug report.
17:07:31 <jds2001> yes
17:07:34 <Kevin_Kofler> He doesn't want to require pulseaudio-libs.
17:07:39 <dwmw2> we used to be able to remove pulseaudio completely, if we wanted functional sound.
17:07:41 <jds2001> kde, gnome, any media player
17:07:44 <Kevin_Kofler> But you basically can't install Fedora without it anyway.
17:07:49 <drago01> dwmw2: almost everything related to audio somehow drags it in
17:07:58 <dwmw2> the only thing I was aware of that broke that recently was bluez requiring pulse
17:08:05 <dwmw2> which I complained about at the time.
17:08:08 <nirik> Kevin_Kofler: is that it? Is there a bug or any other record of this?
17:08:08 <Kevin_Kofler> You can remove the main package (unless you need gnome-bluetooth), but not -libs.
17:08:10 <notting> dwmw2: requiring the libs does not require the daemon
17:08:19 <dwmw2> ah, right
17:08:25 <Kevin_Kofler> nirik: https://bugzilla.redhat.com/show_bug.cgi?id=500087#c13
17:08:27 <buggbot> Bug 500087: medium, low, ---, green, NEW, Fluidsynth pulseaudio backend not built
17:08:28 <nirik> you can also just remove the alsa plugin and it never runs.
17:08:57 <skvidal> is fluidsynth much of a common pkg?
17:08:58 <Kevin_Kofler> (It's linked from the my Trac proposal where I make my case.)
17:09:34 <skvidal> 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 <dwmw2> much as I despair of pulse, I think he ought to enable the back end.
17:09:53 <notting> 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 <dwmw2> skvidal: isn't that what makes it a coherent distribution rather than a random collection of packages?
17:10:18 <skvidal> notting: gotta love the nuclear option
17:10:33 <skvidal> dwmw2: so if we want coherency we want to have N desktops?
17:10:38 <skvidal> and their different themes?
17:10:50 <dwmw2> hm?
17:10:58 <Kevin_Kofler> We share a look&feel as much as possible!
17:11:06 <drago01> sorry but pushing political agendas "get rid of pa" should not be done at the cost of the user expirece
17:11:11 <skvidal> okay
17:11:11 <Kevin_Kofler> In fact we had a flamewar last week over artwork deadlines just because of that.
17:11:12 <skvidal> AGAIN
17:11:20 <skvidal> is fluidsynth all that big of a deal pkg-wise?
17:11:30 <skvidal> am I missing a massive install-base of fluidsynth?
17:11:34 * jds2001 doesn't think so.
17:11:38 <dwmw2> no. Let him orphan it :)
17:11:39 <j-rod> yeah, not widely used
17:11:47 <drago01> I don't know but I don't really care
17:11:48 <skvidal> it's a frelling MIDI INPUT handler
17:11:50 <skvidal> christ
17:12:03 <j-rod> but I think the PA backend should be enabled in it
17:12:06 <Kevin_Kofler> Just because not everyone uses it doesn't mean it shouldn't be built with the integration features upstream provides!
17:12:08 <nirik> 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 <dwmw2> 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 <skvidal> Proposal: leave oget the and fluidsynth the hell alone out in the far reaches of the pkging leafnode space
17:12:34 <skvidal> 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 <skvidal> they just don't really NOT fit, either.
17:12:45 <Kevin_Kofler> I'm for b).
17:12:54 <nirik> I fear c will do nothing. Since he hates pulse and calls it torture.
17:12:57 <dwmw2> skvidal: but this one is _gratuitously_ so.
17:13:03 <skvidal> gratuitously?
17:13:07 <dwmw2> e) ditch pulse completely :)
17:13:07 <Kevin_Kofler> c) will be as useless as a).
17:13:10 <skvidal> to the 5 people who use midis?
17:13:17 <dwmw2> skvidal: there's no good reason for him not to enable the pulse back end.
17:13:22 <Kevin_Kofler> And I have no idea what "other option" d) would be.
17:13:23 <skvidal> I'll cry a single dramatic tear
17:13:23 <notting> skvidal: given he describes the use of the default system as inflicting torture on users?
17:13:23 <dwmw2> hence 'gratuitously'
17:13:24 <nirik> 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 <Kevin_Kofler> dwmw2: Indeed.
17:13:33 <skvidal> notting: so we're all being overly dramatic?
17:13:38 <drago01> dwmw2: s/no good/no/
17:13:39 <notting> skvidal: we?
17:13:42 <skvidal> yes
17:13:46 <Kevin_Kofler> nirik: Right.
17:13:48 <skvidal> he is being dramatic about pulse
17:13:55 <skvidal> and we're being dramatic about the importance of this pkg
17:13:58 <skvidal> b/c it REALLY isn't
17:14:05 <Kevin_Kofler> If he hates PA, he should leave Fedora, entirely.
17:14:09 <Kevin_Kofler> It's our default sound solution.
17:14:14 <drago01> yeah lets say I don't like $hwvendor so I patch my packages to not run on it
17:14:19 <drago01> will fesco be ok with that?
17:14:23 <drago01> I suppose no
17:14:29 <skvidal> Kevin_Kofler: yes - let's draw a line in the sand!
17:14:35 <Kevin_Kofler> drago01: Good point.
17:14:42 <skvidal> drago01: do you really think banning a hw vendor is the same
17:14:45 <Kevin_Kofler> I can patch kdelibs to refuse to run on nvidia hardware tomorrow. :-p
17:14:51 <skvidal> as ONE PKG that is a midi handler?
17:15:06 <dwmw2> Kevin_Kofler: Poulsbo, please :)
17:15:12 <skvidal> I'd say the impact is MANY orders of magnitude different
17:15:19 <drago01> 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 <skvidal> so let's have the appropriate level of drama
17:15:29 <Kevin_Kofler> skvidal: So if ONE PACKAGE is patched to boycott a hardware vendor, that's OK?
17:15:32 <skvidal> drago01: I push an agenda too in yum
17:15:33 <dwmw2> I agree with skvidal that it's not really worth getting worked up about
17:15:41 <j-rod> the package is mostly irrelevant
17:15:44 * jds2001 too
17:15:44 <Kevin_Kofler> That "one package" argument makes no sense.
17:15:46 <j-rod> but the request is perfectly reasonalbe
17:15:48 <skvidal> drago01: it's the 'when shit breaks the user should know' agenda
17:15:54 <dwmw2> except to the extent that it sets a precedent.
17:16:03 <skvidal> dwmw2: but it doesn't set a precedent
17:16:04 <notting> 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 <Kevin_Kofler> Indeed, it sets a precedent.
17:16:07 <skvidal> here I'll phrase it right
17:16:09 <drago01> skvidal: no that is how your software is designed
17:16:22 <j-rod> and "zomg, it'll pull in pulseaudio-libs" hardly seems justification for rejecting a reasonable request
17:16:22 <skvidal> drago01: but I'm PUSHING MY AGENDA THROUGH IT :)
17:16:28 <dwmw2> does anyone actually want to _use_ this package with pulse, or is it just a theoretical objection to oget's package?
17:16:28 <jds2001> dwmw2: we take these on individual case basis.......
17:16:35 <skvidal> dwmw2: ding!
17:16:36 <Kevin_Kofler> dwmw2: I do.
17:16:39 <nirik> 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 <dwmw2> and if someone _does_, are they volunteering to take over the package maintenance?
17:16:52 <skvidal> nirik: how about we cross that bridge when/if we come to it
17:16:58 <skvidal> nirik: instead of a kneejerk reaction
17:17:07 <mjg59> http://markmail.org/message/bovdqb7na3zor2ck - without comment.
17:17:11 * nirik checks his knee. Nope, not jerking. ;)
17:17:43 <drago01> mjg59: ....
17:17:43 * dgilmore is here
17:17:54 <skvidal> right
17:18:02 <skvidal> so oget is a 15 yr old maturity-wise
17:18:09 <skvidal> and sees the world as full of drama
17:18:11 <skvidal> great
17:18:21 <skvidal> let's deal with this problem when it is ACTUALLY a problem
17:18:36 <nirik> isn't it already with users of that package?
17:18:45 <skvidal> the package is a leafnode
17:18:47 <skvidal> NOTHING requires
17:18:48 <skvidal> it
17:18:53 <skvidal> so someone has to be working HARD
17:18:54 <drago01> skvidal: we should deal with issues before they become a real problem ;)
17:18:59 <dwmw2> Kevin_Kofler: are you willing to maintain this package?
17:19:01 <j-rod> but users of it have made a reasonable request
17:19:11 <skvidal> 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 <Kevin_Kofler> dwmw2: Yes.
17:19:22 <jds2001> https://bugzilla.redhat.com/show_bug.cgi?id=500087#c13
17:19:24 <buggbot> Bug 500087: medium, low, ---, green, NEW, Fluidsynth pulseaudio backend not built
17:19:26 <Kevin_Kofler> But he's threatening to orphan everything that depends on it too. :-/
17:19:29 <j-rod> yeah, that one
17:19:31 <Kevin_Kofler> And I have no idea how much that is.
17:19:35 <notting> skvidal: 500087. the original request was from a users, not from kkofler
17:19:42 <dwmw2> Kevin_Kofler: nothing, according to skvidal
17:19:45 <drago01> dgilmore: building the backend does exactly that (it will work with pulse or without)
17:19:45 <Kevin_Kofler> notting: Right.
17:19:58 <Kevin_Kofler> dwmw2: At least qsynth depends on it.
17:19:59 <notting> 'from a users'. geez, can't type.
17:20:07 <dwmw2> oh
17:20:07 <Kevin_Kofler> You need to check the deps on fluidsynth-libs, not fluidsynth.
17:20:07 <jds2001> so here's my issue
17:20:20 <jds2001> i dont want to set precedent of micromanagement
17:20:39 <drago01> define "micromanagement"
17:20:40 <Kevin_Kofler> 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 <jds2001> but this particular packaging decision is hair-brained
17:20:44 <dwmw2> 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 <jds2001> 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 <Kevin_Kofler> I also don't see this as micromanagement.
17:21:08 <skvidal> jds2001: and responding to it is just continuing the drama - and I assure you we'll get more bs from it
17:21:16 <drago01> nirik: echo "please enable pulse" > /dev/null
17:21:28 <nirik> 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 <Kevin_Kofler> drago01: Yeah, that's what "asking nicely" will acheive. ^^
17:21:45 <jds2001> so let's end this at 1730
17:21:45 <mjg59> 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 <Oxf13> comment from the sidelines.  It appears that one would have to /break/ pulseaudio in order to use this package
17:21:58 <dwmw2> how about just asking of Kevin_Kofler can take over maintenance, without oget orphaning other packages in protest.
17:22:06 <Oxf13> so in order to use this package, other packages that depend on the alsa pulseaudio plugin would be broken
17:22:18 <Oxf13> I don't think that's something the project should condone.
17:22:35 <jds2001> Oxf13: huh? aiui, this particular app cant use pulse
17:22:45 <jds2001> it doesn't actively break it for other users.
17:22:53 <j-rod> yes it does
17:22:54 <nirik> jds2001: you must remove pulse currently to use it.
17:22:58 <Oxf13> Simple software synthesizer using vkeybd and fluidsynth doesn't work unless I
17:23:01 <Oxf13> remove alsa-plugins-pulseaudio
17:23:04 <nirik> so anything that uses pulse will not work on your machine when it's removed.
17:23:11 <jds2001> oh, well that's just not cool.
17:23:20 <Kevin_Kofler> If something uses direct ALSA or JACK, it takes the device away from PA users.
17:23:25 <Oxf13> description from the bug.
17:23:26 * jds2001 is not a huge desktop guy, sorry for my lack of education.
17:23:30 <drago01> Oxf13: yeah building the pa backend will fix that
17:23:36 <wwoods> right, and the maintainer actively hates pulseaudio and has intentionally crafted his packages to conflict with it
17:23:46 <Oxf13> this should not be tolerated
17:23:53 <skvidal> ugh
17:23:59 <Kevin_Kofler> (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 <skvidal> it's one thing to disable a feature you don't want
17:24:10 <drago01> even if it is orphaned and nobody picks it up it is better than the current state imho
17:24:15 <skvidal> it's a whole other to fuck with features for everyone else
17:24:15 <nirik> 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 <drago01> skvidal: so you do get my point (about pushing agendas at the cost of users)
17:24:47 <skvidal> I thought this was only impacting the one leafnode no one uses
17:24:49 <skvidal> drago01: no
17:24:53 <skvidal> drago01: that's not the same thing
17:25:00 <skvidal> if I want to pkg something WHICH ONLY IMPACTS MY PACKAGE
17:25:02 <skvidal> I should be able
17:25:03 <skvidal> to
17:25:14 <skvidal> he wants to pkg something which screws with OTHER people's pkgs as a result
17:25:18 <skvidal> that's different
17:25:24 <skvidal> 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 <nirik> (but only on those machines where people install/want to use this)
17:25:33 <skvidal> if I want to mow my yard in some way
17:25:37 <drago01> so a %post rm -rf / in my own package is fine ;)
17:25:37 <Kevin_Kofler> skvidal: That's the whole reason I'm bringing this to arbitration.
17:25:45 <skvidal> Kevin_Kofler: that was not AT ALL clear
17:25:48 <Oxf13> skvidal: I think drago01 was trying to say if he added a apckage that required the removal of NM to work
17:26:01 <skvidal> Oxf13: again - that was not, AT ALL clear from the discussion
17:26:11 <skvidal> Oxf13: thank you for making it clear
17:26:17 * jds2001 is also just receiving this education.
17:26:19 <Oxf13> not from the discussion no, but a 10 second look at the bug turned it up
17:26:19 <drago01> skvidal: well that was what I was trying to say
17:26:39 <notting> 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 <j-rod> so, back to our options...
17:27:04 <skvidal> Oxf13: forgive me for misunderstanding then - it seems like I wasn't the only one who misunderstood
17:27:25 <nirik> proposal: someone asks nicely. if that doesn't work, orphan package for another maintainer?
17:27:26 <jds2001> so let's just vote on the options presented before, taking into account the new information.
17:27:31 <dgilmore> notting: right,
17:27:35 <dwmw2> 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 <jds2001> nirik: +1
17:27:58 <jds2001> dwmw2: +1 to that too.
17:28:10 <notting> +1 to either
17:28:13 <dwmw2> 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 <sharkcz> +1 to either too
17:28:29 <skvidal> +1 sure
17:28:42 <notting> 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 <jds2001> so what are we agreeing to for the minutes? :D
17:29:03 <j-rod> yeah, I'm slightly confused what we're agreeing to
17:29:07 <skvidal> 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 <jds2001> skvidal: fat chance :D
17:29:26 <Kevin_Kofler> How can I work with somebody who just says "no".
17:29:29 <Kevin_Kofler> -. +?
17:29:30 <dgilmore> but if oget wont then Kevin_Kofler taking over is fine.  so +1 to dwmw2's proposal
17:29:36 <skvidal> dgilmore: I would prefer that I could mix vingear and baking soda and not have it fizz
17:29:46 <Kevin_Kofler> Building the subpackage is trivial.
17:29:46 <j-rod> 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 <dwmw2> "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 <dgilmore> skvidal: :)  but that cleans your drains
17:30:04 <drago01> but well....
17:30:04 <Kevin_Kofler> Uh, not subpackage, sorry.
17:30:04 <Kevin_Kofler> The feature.
17:30:04 <skvidal> dgilmore: it does
17:30:06 <Kevin_Kofler> It can't be a subpackage.
17:30:09 <skvidal> dwmw2: umm - no
17:30:15 <Kevin_Kofler> Because the backends are static parts of the one fluidsynth shared object.
17:30:17 <skvidal> dwmw2: that seems overly general
17:30:17 <dwmw2> It _could_ be a subpackage; just requires a little real maintenance instead of packagemonkeying :)
17:30:21 <skvidal> let's just say
17:30:34 <skvidal> your pkg should not break other features if they are being used
17:30:38 <skvidal> or better yet
17:30:45 <skvidal> dear oget: this is how it has to be
17:30:48 <Kevin_Kofler> Enabling the feature is just the question of adding a BR and maybe a configure switch in any case.
17:30:50 <jds2001> Kevin_Kofler: do you agree to take over as maintainer if oget refuses to add the feature?
17:30:55 <skvidal> and we address any others on a case by case basis
17:30:58 <Kevin_Kofler> jds2001: Yes.
17:31:23 <drago01> skvidal: case by case would be "micromanagement"
17:31:35 <drago01> a generall rule should fix that once and for all
17:31:35 <nirik> so, Kevin_Kofler will ask one last time and failing that will take over and make it so?
17:31:48 <skvidal> a general rule saying your pkg must be compliant with the vague 'features of the distro' is worse
17:31:57 <skvidal> nirik: that sounds round to me
17:32:01 <jds2001> #agreed PA backend for fluidsynth must be built. If the current maintainer refuses, Kevin_Kofler will take over as maintainer.
17:32:09 <XulWork> skvidal: s/must/should try/
17:32:10 <j-rod> +1 to that.
17:32:12 <drago01> skvidal: well add another rule that requires common sense
17:32:14 <skvidal> drago01: a general rule is NOT going to fix it - it's going to make us have more of these arguments
17:32:14 <drago01> done
17:32:15 <jds2001> sound correct?
17:32:24 <skvidal> drago01: common sense is frequently neither
17:32:26 <j-rod> worksforme
17:32:37 <nirik> +1 here. Hopefully it will all work out and we can all just get along. ;)
17:32:38 <jds2001> awesome.
17:32:39 <skvidal> jds2001: +1
17:32:40 <drago01> skvidal: (wasn't serious about the last one)
17:33:08 <Kevin_Kofler> Yeah, sounds correct, can we move on now?
17:33:16 <jds2001> yeppers
17:33:17 <dwmw2> +1
17:33:34 <jds2001> #topic legally objectionable, binary and non-free items
17:33:40 <jds2001> .fesco 264
17:33:42 <zodbot> 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 <nirik> I'm still confused by the language here.
17:34:03 * jds2001 gets the intent
17:34:12 <XulWork> isn't this already a guideline?
17:34:20 <Kevin_Kofler> XulWork: No.
17:34:28 <nirik> 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 <Kevin_Kofler> We just ban the evil content itself, not stuff which doesn't work without it.
17:34:35 <nirik> nothing currently in the distro is affected?
17:34:42 <skvidal> did we ever find out what the group is who wanted to put something in?
17:34:44 <Oxf13> nirik: no there would be things affected.
17:34:47 <Kevin_Kofler> The problem is that there's some contention about what "doesn't work without" the bad code.
17:34:54 <nirik> Oxf13: ok, do we have a list of such?
17:35:24 <XulWork> 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 <Oxf13> er, didn't you just post a list of things that would be affected?
17:35:41 <nirik> can someone define "code dependency" ?
17:35:46 <jds2001> skvidal: does it matter?
17:35:52 <Kevin_Kofler> libdvdread is perfectly functional without libdvdcss, it just doesn't support encrypted DVDs.
17:35:57 <dwmw2> a dvd player doesn't require libdvdcss. ∃ unencrypted DVDs.
17:35:58 <nirik> Oxf13: not that I know of. It was a list of things from a thread a while back that I posted.
17:35:59 <Kevin_Kofler> But it can read an unencrypted DVD just fine.
17:36:02 <dwmw2> it does, however, require mpeg support :)
17:36:11 <skvidal> jds2001: no - I'm just curious about it
17:36:20 <Kevin_Kofler> Like one which has been previously un-CSSed and burned without encryption. ;-)
17:36:20 <XulWork> i was just using a hypothetical example
17:36:40 <XulWork> 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 <Oxf13> Could have sworn there was something in the Electronics Lab that would be hit by this
17:36:52 <jds2001> libvdpau is fine - it does not require non-free stuff in the "runtime operating environment"
17:37:00 <dgilmore> Oxf13: there is
17:37:09 <jds2001> it can be used with remote non-free stuff
17:37:14 <Kevin_Kofler> jds2001: I think in this example it's really just a lame excuse.
17:37:15 <nirik> so this would affect all the mpd frontends?
17:37:21 <dwmw2> no, those are just clients
17:37:24 <dwmw2> to a remote server
17:37:25 <Kevin_Kofler> Who in their right mind would use accelerated video over X11 forwarding???
17:37:29 <nirik> or those are ok, because they are just calling to remote?
17:38:24 <Kevin_Kofler> The vast majority of uses (like 99.9+%) will be with proprietary drivers on the machine itself. :-/
17:38:30 <j-rod> at this time, yes, probably
17:38:34 <j-rod> but so what. that's not relevant.
17:38:53 <j-rod> we've already been over this
17:38:55 <Kevin_Kofler> But clients for remote servers are indeed tolerable according to that proposed guideline (or at least that's spot's intent).
17:39:06 <notting> spot: so, what's the impetus package/review?
17:39:53 <nirik> 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 <Kevin_Kofler> 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 <jds2001> no, i think it's like the realplayer download thing (at least on windows) - you install some small thing
17:40:38 <jds2001> and it downloads some other huge blob
17:41:02 <jds2001> there are a number of installers like that, and i suspect this is one of those type of things.
17:41:10 <nirik> which it links to/calls... ie, code, not content.
17:41:20 <jds2001> right
17:41:48 <Kevin_Kofler> Hmmm, Codeina fits that definition, really.
17:42:11 <jds2001> not really, codeina does nothing by itself.
17:42:21 <Kevin_Kofler> Isn't that kinda the point?
17:42:26 <nirik> Kevin_Kofler: a) it's gone, b) it doesn't require downloaded things to be usefull.
17:42:53 <jds2001> nirik: you beat me :)
17:42:53 <jds2001> 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 <j-rod> 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 <j-rod> *that* is the sort of thing we're trying to prevent here, no?
17:43:41 <dgilmore> j-rod: there is something in the electronics lab that needs propietary something to work
17:43:46 <jds2001> 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 <dwmw2> kind of. Although if it required stuff which is in rpmfusion, I'd be OK with that :)
17:44:03 <dgilmore> we let it in because there is a free and open in development
17:44:12 <Kevin_Kofler> dgilmore: No, we voted not to allow it.
17:44:23 <j-rod> hm, I vaguely recall that discussion, but not much of the details...
17:44:26 <spot> notting: package is not currently under review
17:44:28 <dgilmore> Kevin_Kofler: i thought we ended up saying yes
17:44:34 <nirik> dgilmore: that was free content for non free software (with free in development)
17:44:38 <dgilmore> im happy if im wrong
17:44:46 <dgilmore> nirik: ahh right
17:45:03 <nirik> we voted to wait until their was a free software that could use it, IIRC.
17:45:14 <jds2001> dgilmore: and even then, we said come back with some free software that can use it.\
17:45:14 <Kevin_Kofler> 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 <nirik> Kevin_Kofler: that would be good news.
17:45:43 <nirik> anyhow, shall we vote here? or is there additional discussion?
17:45:46 <Kevin_Kofler> But the FEL folks certainly know better than me what the state of that stuff is.
17:46:03 <j-rod> +1 to the latest draft
17:46:28 <nirik> +1 here as well.
17:46:29 <Kevin_Kofler> +1 to spot's proposal
17:46:32 <sharkcz> +1
17:46:36 <dwmw2> +1
17:46:36 <notting> given that it doesn't affect anything current, sure, +1
17:46:37 <skvidal> +1
17:46:42 <jds2001> +2
17:46:44 <jds2001> +1
17:46:59 * nirik wonders why jds2001 gets 3 votes. ;)
17:47:00 <jds2001> #agreed spot's proposal is accpeted.
17:47:03 <jds2001> lol
17:47:03 <Kevin_Kofler> (It might even not be strict enough, but it's definitely an improvement over the status quo.)
17:47:08 <dgilmore> +1 it clears up what we have always said
17:47:28 <spot> thanks guys, i think this will clarify things quite a bit
17:47:55 <jds2001> cool, next step is to recurit someone to write this up on the wiki
17:47:59 <skvidal> spot: I'd still love to know who was gaming the system :)
17:48:10 <spot> skvidal: ask me in toronto over alcohol.
17:48:18 <skvidal> spot: okie doke
17:48:22 * dgilmore taks a bottle of jack for spot
17:48:27 <dgilmore> takes even
17:48:30 <pingou> one ?
17:48:31 * nirik notes it has to be spot or packaging folks, as they are the only ones who can edit the packaging namespace on the wiki
17:48:35 * jds2001 takes a bottle of scotch :D
17:48:57 <skvidal> jds2001: what is up next on our list?
17:49:08 <jds2001> nirik: does this really go into the packaging namespace?
17:49:11 <jds2001> skvidal: open floor
17:49:13 <abadger1999> spot: Is this an inside the Packaging or outsite teh Packaging namespace policy?
17:49:22 * abadger1999 would like it to be outside.
17:49:26 <nirik> " I am asking FESCo to approve amending the Packaging Guidelines to add the following section under "Legal"."
17:49:32 <nirik> so thats in packaging I think.
17:49:40 <jds2001> oh, OK.
17:49:42 * abadger1999 also acknowledges that we need to reorganize the whole thing though.
17:49:46 <jds2001> it could also be in the Legal namespace.
17:50:01 * nirik nods.
17:50:18 * spot will do the writeup today
17:50:29 <jds2001> k
17:50:47 <jds2001> #topic open floor
17:51:00 <abadger1999> jds2001: Any status reports for writeups?
17:51:19 <jds2001> abadger1999: i wasnt aware any were pending :D
17:51:39 <abadger1999> Ok.  Missed the last meeting maybe they all got done.
17:51:54 <abadger1999> How about status report on mediawiki?  Kevin_Kofler?
17:52:05 <nirik> there were some listed in the ticket about doing writeups I thought.
17:52:05 <jds2001> oh, good one :)
17:52:18 * jds2001 must have missed that
17:52:32 <nirik> .fesco 261
17:52:34 <zodbot> nirik: #261 (Followup on documenting FESCo decisions on wiki) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/261
17:53:03 <jds2001> oh, it was the renaming packages policy
17:53:12 <jds2001> which is a packaging policy, no?
17:53:21 <Kevin_Kofler> abadger1999: Well, I did some cleanups to the pages which were clearly outdated, I'll have to check if there's more stuff needing fixing.
17:53:25 <nirik> and the simplify non responsive process
17:53:41 <jds2001> ok, yeah that one needs to be done.
17:53:45 <jds2001> who wants that?
17:54:08 <nirik> renaming packages should be under fesco (for now I guess)
17:54:23 <nirik> I can take the simplify non responsive.
17:54:34 <jds2001> nirik: you mean FPC?
17:54:51 <abadger1999> jds2001: Well, from mypoint of view, the how to perform the rename is already in the guidelines.
17:54:53 <Kevin_Kofler> Hmmm, the table under https://fedoraproject.org/wiki/Development/Schedule#FESCo_Open_Issues needs fixing still.
17:55:05 <Kevin_Kofler> Or just plain removing.
17:55:06 <nirik> abadger1999: is it? where?
17:55:10 <abadger1999> It's just the fact that a re-review is needed that's not documented
17:55:58 <nirik> abadger1999: can you not just add that there where it talks about renaming?
17:56:14 <abadger1999> nirik: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Renaming.2Freplacing_existing_packages
17:56:26 <nirik> if we add a renaming_policy page under fesco, won't people miss it because they looked at the packaging page?
17:56:27 <abadger1999> nirik: It definitely doesn't belong there.
17:56:45 <abadger1999> nirik: yep.  But they're going to miss it no matter where we put it atm.
17:56:50 <nirik> well, we can do it seperate, but I think thats going to just add to confusion.
17:57:01 <nirik> how do we fix this?
17:57:22 <abadger1999> nirik: You going to be in toronto? :-)
17:57:34 * jds2001 will
17:57:39 <nirik> sadly no, looks like I am gonna miss this one... ;(
17:57:53 <nirik> but I will be on irc.
17:57:56 <jds2001> we also need some non-FPC/FESCo packagers there to tell us if it makes sense.
17:57:56 <abadger1999> My thought is we need to restructure so that there's a definite entry point from non-Packaging: namespace.
17:58:06 <abadger1999> And then the Guidelines are one part of that.
17:58:17 <jds2001> us living this day in and day out, it of course makes sense to us
17:58:29 <abadger1999> https://fedoraproject.org/wiki/FUDCon:Toronto_2009_Packaging_Guidelines_Hackfest
17:58:37 <jds2001> but we need "Joe Six-Pack" to tell us if it make sense to them.
17:58:45 * jds2001 cant believe he just said that
17:58:53 <abadger1999> jds2001: If that link could make it into the meeting summary, that would be great too.
17:59:09 <jds2001> #link https://fedoraproject.org/wiki/FUDCon:Toronto_2009_Packaging_Guidelines_Hackfest
17:59:27 * nirik notes no need to do that...meetbot notes links automagically.
17:59:29 <abadger1999> So yeah, add problems and potential solutions there.
17:59:33 <nirik> ok.
17:59:57 <abadger1999> The one we're discussing right now is: https://fedoraproject.org/wiki/FUDCon:Toronto_2009_Packaging_Guidelines_Hackfest#FESCo_and_Packaging_Guidelines_Disunion
18:00:28 <nirik> yeah, not easy, but needs work for sure.
18:00:46 <abadger1999> Which is Packaging: is convenient to shove things in because it's central... but it's not supposed to be for these kinds of"What you can package" decisions.
18:01:08 <abadger1999> The organization is wrong for that.... we have to fix it.
18:01:28 <nirik> yeah, totally agreed.
18:02:33 <abadger1999> Anyhow -- someone needs to take the writeup item for this.
18:02:47 <jds2001> define "this" :)
18:02:47 <nirik> so for now put it under fesco space?
18:03:10 <Kevin_Kofler> I think the biggest issue in the wiki is the lame way pages are now named, the old hierarchical way was much nicer.
18:03:13 <nirik> the renaming packages policy... basically: "You must submit the new package name for review as if it was a new package"
18:03:15 <Kevin_Kofler> The URLs were easier to remember.
18:03:30 <nirik> Kevin_Kofler: yeah, I think so too... flat namespace is kinda weird.
18:03:40 <jds2001> Kevin_Kofler: lots of groups have a category page as their front page
18:03:44 <abadger1999> nirik: yep.  ANd link to Packaging:NamingGuidelines#Renaming.2Freplacing_existing_packages
18:03:45 <Kevin_Kofler> Now we have stuff like New_package_process_for_existing_contributors instead of PackageMaintainers/NewPackageProcess, how's that easier to type?
18:04:03 <jds2001> it's easier to find.
18:04:03 <dgilmore> Kevin_Kofler: it makes it easier to search
18:04:15 <Kevin_Kofler> Also PackageMaintainers/Join vs. Join_the_package_collection_maintainers
18:04:17 <nirik> ok, I guess I can do that one too unless someone else wants to step up?
18:04:24 <Kevin_Kofler> But it breaks things for people like me who remember the URLs and type them.
18:04:31 <dgilmore> Kevin_Kofler: the old moin style of page naming breaks mediawikis searching
18:04:48 <jds2001> Kevin_Kofler: there are redirects for the old locations
18:05:00 <Kevin_Kofler> Yeah, thankfully...
18:05:10 <Kevin_Kofler> But new pages by definition don't have "old locations". ;-)
18:05:20 <jds2001> true :)
18:06:08 <abadger1999> Kevin_Kofler: Perhaps something similar to the Infrastructure and Rel-Eng SOP pages shortcuts.
18:06:25 <jds2001> yeah, exactly
18:06:38 <abadger1999> Kevin_Kofler: http://fedoraproject.org/wiki/ISOP:DB
18:07:10 <abadger1999> I'd talk to docs about doing something in this area, though.
18:08:13 <jds2001> anyhow, anything else?
18:08:30 * jds2001 has lots of $DAYJOB stuff to attend to :D
18:09:42 * jds2001 ends the meeting in 30
18:10:31 <jds2001> er, rather *stops* the meeting. Just to make mmcgrath happy :D
18:10:35 <jds2001> #endmeeting