17:00:15 <jds2001> #startmeeting FESCo meeting 20091016
17:00:15 <zodbot> Meeting started Fri Oct 16 17:00:15 2009 UTC.  The chair is jds2001. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:18 <jds2001> #chair dgilmore dwmw2 notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler
17:00:18 <zodbot> Current chairs: Kevin_Kofler dgilmore dwmw2 j-rod jds2001 nirik notting sharkcz skvidal
17:00:29 <dwmw2> ooh
17:00:31 * sharkcz is here
17:00:33 <dwmw2> it's Friday
17:00:34 * notting is here
17:00:48 * dwmw2 won't be here next week; it's JLS
17:01:01 <jds2001> cool
17:01:08 <Kevin_Kofler> Present.
17:01:18 <jds2001> alrighty, lets get started....
17:01:42 <jds2001> #topic zsync shipping internal zlib
17:01:50 <jds2001> .fesco 134
17:01:51 <zodbot> jds2001: #134 (Approval needed - zsync needs to ship internal zlib for rsync compatibility) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/134
17:02:01 * jds2001 not sure what the new information is.
17:02:42 <sharkcz> there was some movement in the bug, it was one step forwards and one step backwards
17:02:57 * jds2001 just saw a new version
17:03:03 <jds2001> and a patch that wound up not working
17:03:05 <Kevin_Kofler> I still think we should just approve the exception.
17:03:26 <Kevin_Kofler> We've seen how far the attempts to do without the forked zlib went (nowhere!).
17:03:29 <dwmw2> er, what does rsync do?
17:03:36 * dgilmore is present
17:03:42 <jds2001> dwmw2: ships with an internal zlib :(
17:03:46 <Kevin_Kofler> So now we have further evidence that the exception is needed and should reconsider our "no".
17:03:52 * jds2001 not sure if simo fixed that or not.
17:03:59 <dwmw2> seems a little odd to allow one  but not the other
17:04:00 <jds2001> though he said that would be easy
17:04:09 <dwmw2> otoh, forcing them to _share_ one might be reasonable
17:04:12 <jds2001> dwmw2: we dont allow rsync, we said it had to be fixed.
17:04:21 <jds2001> dwmw2: yeah, that came up too
17:04:21 <dwmw2> ah, right. that makes more sense
17:04:23 <dgilmore> dwmw2: we did not allow rsync  its a historical artifact that needs fixing
17:04:31 <Kevin_Kofler> jds2001: Huh? He said it's impossible to fix without making rsync incompatible with older Fedora, RHEL/CentOS and all other distributions.
17:04:35 <notting> and yet, we're not actually acting on rsync
17:05:00 <jds2001> i thought we asked simo
17:05:05 <jds2001> and he said that wouldn't be an issue
17:05:06 <Kevin_Kofler> As in, you need to use the same zlib on both ends.
17:05:39 <dgilmore> i dont see any new ideas in teh ticket
17:05:44 <dgilmore> am i missing something?
17:06:19 <jds2001> dgilmore: i didnt either, except a patch that failed to function.
17:06:36 <dgilmore> jds2001: and mention of new ideas
17:07:23 <jds2001> so what do we do, defer for want of more information?
17:07:23 <notting> so, looking at that, i only see two courses of actions we can take today - vote to allow the exception for both, or punt until later
17:07:49 * jds2001 wants a date on "later" if that's what we decide to do.
17:07:54 <jds2001> We're horrible about that :(
17:08:24 <dgilmore> notting: i say punt till later.
17:08:32 <notting> so, to handle the first part: re-vote: allow zsync and rsync to have an exception to their bundled zlib?
17:08:34 * jds2001 too
17:08:53 <Kevin_Kofler> +1 to allow the exception, I still see no alternative solution.
17:09:02 <Kevin_Kofler> The library is modified, so we can't just use the system copy.
17:09:03 <jds2001> -1 I guess, bundled libs are bad.
17:09:04 <dgilmore> notting: if they really need it we should rip out and make a single copmatible zlib for both
17:09:11 * jds2001 wants rsync to officially fork
17:09:33 <jds2001> and provide a zlib that both can use
17:09:36 <dgilmore> rather than lots of copies lets limit it to 2 copies of zlib
17:09:44 <dgilmore> jds2001: :)  right
17:09:52 <dgilmore> zlib-rsync-fork
17:10:01 <sharkcz> -1, a forked zlib is a solution for me
17:10:13 <jds2001> -1, with sharkcz
17:10:16 <dgilmore> -1 to an exception
17:10:25 <dwmw2> can we get our rsync package to spit out a zlib-rsync-fork package, for zsync to use?
17:10:39 <Kevin_Kofler> dwmw2 has an idea there.
17:10:43 <dwmw2> and still -1 to zsync having its own
17:10:47 <Kevin_Kofler> I suspect it'll need makefile modifications.
17:10:54 <dgilmore> acceptable would be a forked copy that can be shared. or merging the missing bits into zlib upstream
17:11:02 <Kevin_Kofler> rsync is probably linking it directly into the executable, or at most building it static and linking it in.
17:11:10 <notting> skvidal: j-rod: nirik: opinions?
17:11:15 <Kevin_Kofler> We'd have to change it to produce a shared library.
17:11:17 <dgilmore> dwmw2: i think that is our winning path
17:11:42 <jds2001> s/we'd/rsync upstream, preferrably
17:12:05 * notting is a weak +1 to the exception, in that i do not want us to have to fork rsync
17:12:26 <jds2001> notting: is getting it upstream hopeless?
17:12:49 <notting> don't know. but it would certainly be more invasive than most changes we make upstream
17:13:09 <jds2001> but it benefits all downstreams.
17:13:12 <notting> in any case, w/o responses from *all* of nirik, j-rod, skvidal, the exception can't pass
17:13:31 <notting> which leaves punting and suggesting they split out the modified zlib into a separate package
17:14:55 <jds2001> #agreed reiterated that both rsync and zsync cannot have bundled zlib.  Suggestion is to split out as a shared lib from rsync.
17:15:06 <jds2001> on to some F13 features
17:15:15 <jds2001> #topic noveau displayport
17:15:20 <jds2001> .fesco 258
17:15:21 <zodbot> jds2001: #258 (Noveau DisplayPort - https://fedoraproject.org/wiki/Features/NouveauDisplayPort) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/258
17:15:41 <jds2001> +1 - this is 1/3 of the feature from F12 that didn't make it.
17:15:43 <sharkcz> +1
17:15:48 <notting> +1, seems pretty clear.
17:15:51 <dwmw2> +1
17:16:20 <dgilmore> +1
17:16:25 <jds2001> #agreed Noveau DisplayPort feature is accepted for F13.
17:16:31 <jds2001> #topic Radeon DisplayPort
17:16:35 <jds2001> .fesco 259
17:16:36 <zodbot> jds2001: #259 (Radeon DisplayPort - https://fedoraproject.org/wiki/Features/RadeonDisplayPort) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/259
17:16:39 * skvidal is here
17:16:46 <skvidal> my network went away
17:16:57 <jds2001> skvidal: glad you found it :D
17:17:00 * skvidal is reading scrollback now
17:17:05 <skvidal> jds2001: frelling irritating
17:17:09 * jds2001 pauses
17:17:17 <Kevin_Kofler> +1 to RadeonDisplayPort (and for the record, +1 to NouveauDisplayPort as well)
17:17:34 <notting> +1 to RadeonDP, same reason
17:17:38 <dwmw2> +1
17:17:40 <sharkcz> +1
17:17:51 <jds2001> +1
17:17:52 <dgilmore> +1
17:18:16 <skvidal> +1 to radeondp
17:18:21 <jds2001> #agreed Radeon DisplayPort feature is accepted for F13.
17:18:32 <jds2001> skvidal: anything on previous topics?\
17:19:02 <skvidal> yes one sec
17:19:11 * nirik is finally here.
17:19:14 <skvidal> -1 on the zlib thing
17:19:39 <jds2001> ok, then that's doubly official now
17:20:04 <jds2001> #topic SIP Witch Domain Telephony
17:20:09 * nirik would vote, but isn't sure what +1/-1 mean here... I am still -1 to granting an exception.
17:20:16 <jds2001> .fesco 260
17:20:17 <zodbot> jds2001: #260 (SIP Witch Domain Telephony - https://fedoraproject.org/wiki/Features/SIP_Witch_Domain_Telephony) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/260
17:20:37 <nirik> +1 here on this one. Sounds cool.
17:20:45 <Kevin_Kofler> +1 to SIP Witch, anything that can fight Skype is a good thing!
17:20:52 <jds2001> +1, sounds cool
17:20:54 <sharkcz> +1
17:21:03 <jds2001> Kevin_Kofler: i read it as more of an asterisk replacement
17:21:06 <jds2001> am i wrong?
17:21:12 <Kevin_Kofler> (Skype's lock-in relies on the networking effect to spread like a virus.)
17:21:29 <dwmw2> jds2001: it doesn't do media processing.
17:21:29 <dgilmore> +1
17:21:29 <jds2001> same with twitter :/
17:21:33 <dwmw2> it's just about _routing_, I think
17:21:38 <Kevin_Kofler> Well, the feature page says: "Offering a means to create and deploy scalable, secure, and publicly controlled alternative to Skype architecture as well as secure VoIP solutions for workgroups and other entities using entirely free software and ANY standard's compliant SIP client, many of which are already packaged for Fedora."
17:21:43 <dwmw2> not entirely sure what user-visible feature it really offers
17:21:44 * jds2001 uses twitter all the time
17:21:51 * j-rod_ very tardy...
17:21:54 <notting> yeah, i'm a little confused how to the user will notice this
17:22:05 <dgilmore> jds2001: i dont see it as an asterisk replacement
17:22:16 <dgilmore> but kinda like upnp for sip
17:22:22 <Kevin_Kofler> dwmw2: You'd still use the standard SIP for the actual media processing.
17:22:23 <skvidal> so like avahi?
17:22:31 <dgilmore> take away some complexity from users
17:22:33 <jds2001> ok, that makes sense
17:22:37 <notting> dgilmore: ok, given that, +1
17:22:48 <dwmw2> or like a stun proxy?
17:22:58 <dgilmore> skvidal: dwmw2 right
17:22:59 <nirik> it's likely going to take people reading release notes, or reading a blog to notice it I suspect.
17:23:02 <dgilmore> dwmw2: ricky
17:23:04 <dgilmore> gahh
17:23:13 <dgilmore> nirik: likely yeah
17:23:26 <dgilmore> ill certainly give it a whirl i think
17:23:28 <Kevin_Kofler> It appears to be an alternative to STUN which doesn't rely on the UDP tunneling hack which doesn't work with some forms of NAT.
17:23:38 <Kevin_Kofler> sipwitch does actual proxying/forwarding.
17:23:45 <Kevin_Kofler> At least that's how I read the description.
17:23:45 <dwmw2> and it runs on the local machine, instead of on a remote server
17:23:47 <dwmw2> ?
17:24:07 <dgilmore> dwmw2: looks like it runs locally
17:24:11 <jds2001> i think so, but there's mention that sipwitch can die and calls will continue
17:24:13 * skvidal puts this in the <shrug> category
17:24:22 <skvidal> what do we gain and what do we lose - other than one more pkg?
17:24:27 <dwmw2> so how does it _help_ me connect to a remote SIP server, if I'm behing NAT or something?
17:24:39 <dgilmore> skvidal: we are in with the cool kids?
17:24:43 <Kevin_Kofler> So should we suggest to them to make more user-understandable documentation? :-)
17:24:46 <dwmw2> skvidal: we don't gain or lose the package, surely? The feature process is about what we want to make a song and dance about
17:25:04 <Kevin_Kofler> If even we get confused, users definitely will. :-(
17:25:06 <skvidal> dwmw2: so what the hell difference does it make?
17:25:11 <dwmw2> and if we're going to do that with sip witch, I think we really _do_ want them to write something understandable about what benefits it provides for the user
17:25:14 <dwmw2> thus, -1
17:25:37 <skvidal> dwmw2: I'd say +1 contingent on better documentation
17:25:44 <dwmw2> but feel free to try again, preferably with specific use case examples (the gnome folks do these well)
17:25:57 <dwmw2> skvidal: er, yeah. I could phrase it that way too.
17:26:15 <skvidal> :)
17:26:36 <jds2001> #agreed SIP Witch is accepted as an F13 feature, contingent on better user-facing documentation
17:26:36 <dwmw2> "not until/unless you explain how it actually benefits the user"
17:26:38 <j-rod_> I'm convinced for a -1 for now
17:26:50 <jds2001> oh
17:27:22 <jds2001> so im confused - on the +1 side, we have me, sharkcz, and Kevin_Kofler for sure
17:27:39 <jds2001> skvidal and dwmw2 seem to be as well, but I could be wrong.
17:27:42 <dwmw2> I'd prefer to say -1 today, and have them come back with better documentation _before_ we approve it
17:27:53 <jds2001> ok, there
17:27:53 * nirik was also +1
17:27:54 <notting> yeah, i'll change my vote to -1
17:28:06 <jds2001> there is still plenty time
17:28:07 <jds2001> #undo
17:28:07 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0xf2715d0>
17:28:21 * nirik thinks either way better docs would be nice.
17:28:25 <Kevin_Kofler> I think more documentation can't hurt indeed.
17:28:48 <skvidal> okay - then let's bounce it back  - get some docs - and then approve if they figure it out
17:28:56 <Kevin_Kofler> So I guess we should request better documentation now (so it's clear what that thing actually DOES), then vote again.
17:29:05 <jds2001> #agreed SIP Witch is rejected as an F13 feature in it's current state, better user-facing documentation is required. Please resubmit with better docs.
17:29:16 <dwmw2> s/it's/its/ :)
17:29:27 <jds2001> english nazi :D
17:30:17 <jds2001> anyhow. that's all I had
17:30:20 <mether> jds2001, I prefer punted to rejected
17:30:55 <jds2001> mether: we did indeed vote it down, and the minutes contain what's required in order for it to pass.
17:31:04 <mether> ok
17:31:20 <jds2001> #topic open floor
17:31:26 <jds2001> anything else?
17:32:28 * jds2001 ends the meeting in 30
17:32:38 <sharkcz> the rsync thing - I will try to prepare a patch to create shared lib from the forked zlib
17:32:49 <sharkcz> so we move somewhere ...
17:32:58 <jds2001> thx sharkcz :)
17:33:09 <jds2001> #endmeeting