14:32:50 <Kevin_Kofler> #startmeeting KDE SIG Meeting
14:32:50 <zodbot> Meeting started Tue Aug  6 14:32:50 2013 UTC.  The chair is Kevin_Kofler. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:32:50 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:32:56 <Kevin_Kofler> #meetingname kde-sig
14:32:56 <zodbot> The meeting name has been set to 'kde-sig'
14:33:01 <Kevin_Kofler> #topic Role call
14:33:05 <Kevin_Kofler> So, who's present?
14:33:31 <Kevin_Kofler> (other than me :-) )
14:33:37 <than_> present
14:33:38 <jgrulich> present
14:34:02 <rdieter> hi
14:35:22 <Kevin_Kofler> #chair than jgrulich rdieter
14:35:22 <zodbot> Current chairs: Kevin_Kofler jgrulich rdieter than
14:35:31 <Kevin_Kofler> #info Kevin_Kofler, than, jgrulich, rdieter present.
14:35:40 <Kevin_Kofler> #topic Agenda
14:35:47 <Kevin_Kofler> So what do we have to discuss?
14:35:55 <Kevin_Kofler> qtchooser
14:35:59 <Kevin_Kofler> Anything else?
14:36:55 <than> kdenetwork split status
14:37:06 <than> kdesdk/kdetoys split
14:37:38 <Kevin_Kofler> Let's start with the splits…
14:37:46 <Kevin_Kofler> #topic kdenetwork split status
14:38:00 <Kevin_Kofler> rdieter: I think that should be yours. :-)
14:38:16 <rdieter> krfb and kget reviews are already done (thanks jgrulich)
14:38:28 <rdieter> imported, and updated kdenetwork to metapackage
14:39:07 <rdieter> err, krdc done, that is
14:39:25 <rdieter> left: kdenetwork-filesharing, kppp, kopete, krfb
14:39:33 <Kevin_Kofler> #info krdc and kget done, kdenetwork updated to metapackage
14:39:41 <Kevin_Kofler> #info left to do: kdenetwork-filesharing, kppp, kopete, krfb
14:39:47 <rdieter> I guess I skipped doing kdenetwork-strigi-analyzers , didn't see the point
14:40:06 <Kevin_Kofler> Well, I think there's still stuff using Strigi.
14:40:13 <Kevin_Kofler> Nepomuk doesn't use it anymore, sure.
14:40:46 <Kevin_Kofler> But Strigi was what all the users of KFile were supposed to port to, at least initially, so I think there is some usage of it around.
14:41:10 <Kevin_Kofler> Anyway, the subpackage was previously there and shouldn't just go away.
14:41:16 <Kevin_Kofler> So I think we should package that too.
14:41:33 <Kevin_Kofler> #info kdenetwork-strigi-analyzers also not done for now.
14:41:40 <rdieter> right, ok.
14:43:46 <Kevin_Kofler> #topic other splits
14:43:49 <mbriza> i should set some alarm to notify me we have a meeting, completely missed the start, sorry
14:43:58 <Kevin_Kofler> #chair mbriza
14:43:58 <zodbot> Current chairs: Kevin_Kofler jgrulich mbriza rdieter than
14:44:08 <Kevin_Kofler> #info mbriza joined late
14:44:24 * rdieter started doing okteta review
14:44:33 <Kevin_Kofler> So there were 3 other splits too: kdesdk, kdetoys and what was the third one again? kdeadmin?
14:44:44 <rdieter> yes
14:44:59 <Kevin_Kofler> #info kdeadmin, kdesdk, kdetoys also split upstream in 4.11.
14:45:07 <Kevin_Kofler> #info rdieter started doing okteta review.
14:45:52 <Kevin_Kofler> A lot of work still to do though. :-(
14:46:31 <Kevin_Kofler> Especially kdesdk has a lot of subpackages.
14:47:20 <mbriza> i'll be glad to take some, i need to practice packaging...
14:47:37 <than> kdesdk/kdetoys/kdeadmin split still on my todo
14:47:59 <than> mbriza, jgrulich: could you please take care of them?
14:48:36 <Kevin_Kofler> #action mbriza to take some of the new split packages.
14:48:54 <mbriza> than: sure
14:48:58 <jgrulich> than: as I said, I'll try what can I do :)
14:49:10 <than> thanks :)
14:49:29 <Kevin_Kofler> #action jgrulich to try, too.
14:49:30 <than> #action jgrulich to take some of the new split packages.
14:49:48 <Kevin_Kofler> I think that's it.
14:49:53 <Kevin_Kofler> Next topic…
14:49:57 <Kevin_Kofler> #topic qtchooser
14:50:33 <Kevin_Kofler> So rdieter took it on his own to force qtchooser through the review and import process and also to spam qtchooser config files into Qt 4 and 5 packaging.
14:50:58 <Kevin_Kofler> (also with the help of a reviewer who either wasn't aware of or ignored the objections to qtchooser getting packaged at all)
14:51:53 <Kevin_Kofler> I still think this thing is broken by design and it's a big mistake to attempt to support it in Fedora.
14:52:21 * rdieter waits to speak in defense
14:52:59 <rdieter> Kevin_Kofler: or are you done?
14:53:00 <Kevin_Kofler> rdieter: Speak on…
14:53:03 <rdieter> ok
14:53:54 <rdieter> I'd hoped to find some compromise over time, but there seems to be nothing that satisfies Kevin_Kofler at least
14:54:22 <rdieter> so while having the kde-sig blessing here would be nice, neither is it required to simply include a package in the distro
14:54:58 <rdieter> lastly, I would argue that there are 2 distinct issues here.  including qtchooser package, and including qtchooser .conf files.
14:55:45 <rdieter> even *if* qtchooser is not in the distro, I would argue strongly that it makes good sense to provide qtchooser .conf files anyway, for those upstream developers who choose to use it (pun intended)
14:56:04 <rdieter> to use qtchooser, that is.
14:56:04 <Kevin_Kofler> Well, qt could Obsolete qtchooser and that'd be a KDE SIG decision.
14:56:21 <rdieter> Kevin_Kofler: I'm pretty sure FESCo would disagree.
14:56:34 <Kevin_Kofler> And the conf files need to go the heck out of qtchooser.
14:56:39 <Kevin_Kofler> *of qt
14:56:50 <rdieter> in a case of disagreeing maintainers, it would set a very bad precedent to get into Obsoletes wars
14:56:52 <Kevin_Kofler> (but they shouldn't be shipped as part of qtchooser either because qtchooser should not be shipped)
14:57:23 <Kevin_Kofler> And also, we can decide not to ship .conf files and then qtchooser would be a "package not useful without external bits", which is not allowed in Fedora.
14:57:38 <rdieter> lastly*2, I argue including qtchooser in the distro is purely harmless.  Its opt-in (ie, only those users who want it, can and will install it)
14:57:40 <Kevin_Kofler> But technicalities aside, the real issue is that this thing is just plain broken.
14:57:51 <rdieter> Kevin_Kofler: irrelavent
14:57:59 <Kevin_Kofler> It breaks reproducibility of build environments pretty badly.
14:58:08 <Kevin_Kofler> I think this is very relevant. We shouldn't be shipping broken packages.
14:58:16 <Kevin_Kofler> We're a distro, not a trashcan for useless stuff.
14:58:37 <rdieter> to address build environment concerns, Id be willing to help draft packging guideilnes forbidding qtchooser be included in any buildroot
14:58:55 <Kevin_Kofler> Do you think we should start packaging viruses, as long as the packages are opt-in?!
14:59:08 <Kevin_Kofler> If a package is harmful, it's better to NOT have it in the distro.
14:59:14 <rdieter> sigh, this discussion is getting silly now.
14:59:36 * rdieter would be willing to continue to a sane and rational discussion...
15:00:05 <Kevin_Kofler> The mere fact that guidelines are required to ensure people will NOT use qtchooser in RPM builds shows that the thing is harmful.
15:00:22 <rdieter> I think everyone gets my and Kevin_Kofler's stance here, please someone else speak
15:00:27 <Kevin_Kofler> And build environment reproducibility is also an issue outside the controlled mock world.
15:00:58 <Kevin_Kofler> Of course, there are plenty of ways people can screw up their build environments, but we shouldn't give them the tools to do it, especially where it's not needed at all.
15:01:08 <Kevin_Kofler> You can use multiple Qt versions in parallel just fine without qtchooser.
15:01:21 <rdieter> qtchooser is upstream's choice tool, mind you.
15:01:39 <Kevin_Kofler> So is Akonadi-MySQL. :-)
15:01:42 <than> rdieter: i don't agree to add somthing which could cause any issue in build enviroment later
15:01:45 <mbriza> well, even though i can't make a fully informed decision on which of these opinions is right, i think that if qtchooser inclusion doesn't affect any other package in any way when it isn't installed, i'd be for including it...
15:02:23 <rdieter> than: that's quite an open-ended criteria.  I can think of many things already in the distro that satisfies that
15:02:48 <than> or to affect the build enviroment
15:03:03 <rdieter> so, hopefully easy one:  lets start with simply including qtchooser .conf files.
15:03:24 <rdieter> them, alone, are purely harmless, and only help those developers to purposely use qtchooser.
15:03:37 <rdieter> there is absolutely no technical reason *not* to include them.
15:03:48 <rdieter> any objections to this (besides Kevin_Kofler )?
15:04:14 <Kevin_Kofler> Including the .conf files is supporting qtchooser.
15:04:15 <than> i have objection to add qtchoose
15:04:34 <rdieter> than: .conf files too?  If so, why?
15:05:19 * rdieter is also curious, for those of you with technical objections to qtchooser, why have you not contacted upstream and expressed them?
15:05:30 <jgrulich> I don't have objection even to qtchooser, since it's opt-in and it's not installed by default, it's up to users whether they want to install and use it
15:05:34 <than> yes conf files too. i don't want any tools which could change the build enviroment
15:06:00 <rdieter> than: the .conf files are not the tool though.  I don't understand. ?
15:06:24 <than> but is it  for qtchoose?
15:06:34 <rdieter> than: yes, of course.
15:06:54 <than> it's why i don't want
15:07:08 <rdieter> what you're saying, is upstream developers who choose purposely to use qtchooser.... they are not allowed to configure their environment using that tool to use the distro copies of Qt libraries
15:07:19 <rdieter> that makes no sense to me
15:08:10 <mbriza> when it's really optional to use then i don't see any reason not to include it... i suppose the "change of the build environment" happens only when the developer really want it to happen
15:08:26 <mbriza> *wants
15:08:26 <rdieter> in effect, we would be sabotaging that qtchooser environment to not 'just work'
15:09:27 <Kevin_Kofler> But that screwed up tool SHOULD NOT "just work".
15:10:13 <rdieter> I think statements like that highlights the irrationality of your argument, sorry.
15:10:54 <rdieter> anyway, I've stated my case.  folks have expressed their opinions.  now what?
15:11:17 <rdieter> me, mbriza, jgrulich seem to be in favor on all accounts.  than, Kevin_Kofler against
15:11:21 <Kevin_Kofler> So, to sum up, it looks like than and me are still unhappy with qtchooser, whereas mbriza, jgrulich and of course rdieter have no objections.
15:11:43 <Kevin_Kofler> Yeah, so far we agree, at least. ;-)
15:12:18 <mbriza> yeah but i don't think i'm informed enough on the topic to be able to decide definitively
15:12:23 * rdieter had hoped we could agree on .conf files at least too. alas... ;(
15:12:29 <Kevin_Kofler> Now what does that mean? Does that mean you're the majority? Should we try to get a position from ltinkl and jreznik?
15:12:55 <rdieter> Kevin_Kofler: i think so
15:13:17 <Kevin_Kofler> You think what? :-)
15:13:24 <Kevin_Kofler> There were 2 questions there.
15:13:42 <Kevin_Kofler> (Well, technically 3, but…)
15:13:57 <rdieter> both.  we are currently in the majority, but I alsl think we should get input from ltinkl, jreznik
15:14:11 <jgrulich> and dvratil
15:14:15 <Kevin_Kofler> Right.
15:14:44 <Kevin_Kofler> Also, the thing is that you are the only one strongly in favor, the others are just "not objecting".
15:14:54 <Kevin_Kofler> Voting is a mess.
15:15:09 <rdieter> poll: anyone here actually *try* using the tool yet?
15:16:00 * rdieter thinks it worth at least *trying* first, even if in the distro.  If real, tangible, significant problems arise, I would have no problem at all withdrawing the package.
15:16:35 * mbriza didn't and /me's still reading about the tool, /me also uses compiled qt master instead of fedora's qt5 packages...
15:16:37 <rdieter> I feel the risk of the theoretical problems mentioned here are overstated
15:17:08 <Kevin_Kofler> Well, I don't know why I should try using qtchooser when CMake will just detect the correct Qt by itself (or if not, it needs to be fixed), or when using qmake directly, I just have to run qmake-qt4 (as I always did) or qmake-qt5.
15:17:32 <rdieter> Kevin_Kofler: and, again, I would argue that is a completely separate issue.
15:17:42 <rdieter> *Both* approaches can and should work
15:18:10 <Kevin_Kofler> You asked whether we had tried it, I told you why not. :-)
15:18:27 <rdieter> though I would agree our standard prefix/postfix methods should first be guaranteed to work, yes
15:18:33 <rdieter> Kevin_Kofler: I didnt ask why
15:19:40 <rdieter> I really dislike arguments like: option a is better than b, so get rid of b altogether
15:23:15 <Kevin_Kofler> So, can we get to SOME conclusion there?
15:23:32 <rdieter> i think we have to wait for more input at least, from those not here atm
15:23:36 <Kevin_Kofler> I don't think it makes sense to keep arguing forever, the meeting time is running out and I have to leave soon.
15:23:48 <rdieter> +1 to that
15:24:47 <rdieter> i will ask that if kde-sig decides against including qtchooser, someone draft an official statement to publicize why.
15:24:57 <Kevin_Kofler> #info rdieter strongly for qtchooser, mbriza and jgrulich don't object, than and Kevin_Kofler do object to it, waiting for input from dvratil, jreznik, ltinkl before claiming a clear consensus.
15:25:11 <rdieter> (which can't be me)
15:25:15 <Kevin_Kofler> #topic Open discussion
15:25:19 <Kevin_Kofler> Anything else?
15:26:40 <mbriza> nothing from my side
15:28:34 <Kevin_Kofler> OK, thanks everyone for coming!
15:28:38 <Kevin_Kofler> #endmeeting