15:14:03 <rdieter_laptop> #startmeeting kde-sig
15:14:03 <zodbot> Meeting started Tue Aug  9 15:14:03 2011 UTC.  The chair is rdieter_laptop. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:14:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:14:23 <rdieter_laptop> #topic roll call
15:14:28 <rdieter_laptop> hi, who's present today?
15:14:38 <rdieter_laptop> #meetingname kde-sig
15:14:38 <zodbot> The meeting name has been set to 'kde-sig'
15:14:56 <Kevin_Kofler> Present.
15:15:01 <rdieter_laptop> #chair Kevin_Kofler than ltinkl rnovacek
15:15:01 <zodbot> Current chairs: Kevin_Kofler ltinkl rdieter_laptop rnovacek than
15:15:02 * rnovacek is here
15:15:38 <rdieter_laptop> #info than sends his regrets
15:16:04 <rnovacek> jreznik is on Desktop Summit
15:16:38 <rdieter_laptop> #info jreznik is at desktop summit
15:17:23 <rdieter_laptop> #topic agenda
15:17:33 <rdieter_laptop> a bit lax this week, didn't have a wiki page or agenda prepared
15:17:45 <rdieter_laptop> the kde-4.7 on f15 topic, was suggested.
15:19:21 <rdieter_laptop> anything else?
15:19:43 <rnovacek> there are only few of us today, I'd let if for next week
15:19:57 <rdieter_laptop> true, let's keep things light then
15:20:17 <rdieter_laptop> #topic f15/kde-4.7
15:20:50 <rdieter_laptop> I've mentioned it onlist a couple times, my feeling is that kde-4.7 (kdepim/kmail2 in particular) is a bit too big a change and invasive
15:21:07 <Kevin_Kofler> So my proposal is, prepare 4.7 minus kdepim(-runtime) and with monolithic packaging (even if kludged together).
15:21:22 <rdieter_laptop> not sure that will work
15:21:26 <Kevin_Kofler> Then see what FESCo thinks of it once we have something concrete to show.
15:21:44 <Kevin_Kofler> It can certainly be made to work with some amount of patching.
15:21:49 <Kevin_Kofler> The only unknown is the amount needed.
15:22:08 <rdieter_laptop> kde-4.7 resuires newer shared-desktop-ontologies-0.7, older kdepim needs < 0.7 I believe
15:22:23 <Kevin_Kofler> This can certainly be patched one way or the other.
15:22:37 <Kevin_Kofler> (Either revert the kdelibs changes which require the newer ontologies or backport the kdepim changes.)
15:23:01 * rdieter_laptop has more doubts that the effort of trying to make this unsupported confuration work
15:24:00 * Kevin_Kofler has done old-libfoo or new-libbar hacks every so often. :-)
15:24:21 <rdieter_laptop> hacks are ok for one-offs, but this is kdepim we're talking about.
15:24:49 <Kevin_Kofler> The latest one I did was in kdepim, and it made Kleopatra work on F15. :-)
15:24:53 <rdieter_laptop> I'm ok with skipping with an official update this time
15:25:22 <rdieter_laptop> can even make a more visible kde47 side repo (other then kde-unstable)
15:25:34 <rnovacek> I'm for skipping too
15:25:47 <Kevin_Kofler> The alternative is, just include kdepim 4.7…
15:25:59 <Kevin_Kofler> I think skipping 4.7 entirely is going to make a bad precedent. :-/
15:26:03 <rnovacek> I don't think it worth the effort to get rid of kmail2
15:26:09 <Kevin_Kofler> And we already have users complaining that 4.7 is not out yet!
15:26:17 <rnovacek> Kevin_Kofler: that's a good point
15:26:17 <Kevin_Kofler> (as an update to F15)
15:26:30 <ltinkl> agree, this will get us bad press if we skip 4.7 completely
15:26:35 <rdieter_laptop> those users don't understand the full consequences of what they're asking for...
15:26:47 <Kevin_Kofler> Our users actually want updates pushed faster, not skipped entirely.
15:26:55 * ltinkl don't think including kmail2 is a good idea either
15:27:08 <Kevin_Kofler> Even waiting for 4.n.1 is making users unhappy.
15:27:21 <kalev> just direct the users to F16 alpha or the side repo
15:27:22 <ltinkl> after having heard the horrific stories of kmail broken everywhere
15:28:42 * rdieter_laptop is torn, would love to be able to pull it (kde-4-7 official update) off, but...
15:30:05 <rnovacek> yes, would be great if we can make it, but I'm not sure...
15:30:37 <rnovacek> packaging and kmail2 is big bunch of changes
15:31:07 <Kevin_Kofler> So we should kludge around those. :-)
15:31:38 <Kevin_Kofler> In fact, I think rushing the split packaging was a mistake, we should have made the monolithic stuff work for F16.
15:32:58 <rnovacek> but creating monolithic packages out of separated tarball can brake same as new splitted packages
15:33:32 <rnovacek> s/tarball/tarballs/
15:33:43 <rnovacek> s/brake/break/
15:33:55 <rnovacek> what's wrong with me?
15:33:57 <Kevin_Kofler> Well, it won't make noticeable changes on the users' systems.
15:34:15 <Kevin_Kofler> And it's easier to compare contents with previous packages.
15:34:58 <rnovacek> yeah, but it can introduce other breakage, like in library linking
15:35:44 <Kevin_Kofler> Checking the build logs is always a good idea…
15:36:25 <rdieter_laptop> and fixing that (in monolithic builds) is sometimes non-trivial. :(  i found out the hard way
15:38:31 <rdieter_laptop> we've probably more than enough to do with trying to fix other real bugs, rather than self-inflicted ones. imo.
15:39:05 <Kevin_Kofler> As I already pointed out, the 4.6 branch tends to have fixes for building stuff in monolithic tarballs, they'd just have to be forward-ported.
15:40:03 <Kevin_Kofler> In fact, there are 3 fixing techniques: forward-porting, reverting and custom patching, depending on the situation.
15:40:14 <Kevin_Kofler> But there isn't really anything that's not fixable. :-)
15:40:49 <Kevin_Kofler> The only problem is, we started way too late, because we focused on split packaging all this time.
15:41:05 <rdieter_laptop> well the "because" is several reasons
15:41:15 <Kevin_Kofler> (Well, actually we haven't started yet, even.)
15:41:23 <rdieter_laptop> we waited, hoping for upstream to fix the monolithic problem (and they didn't)
15:41:40 <Kevin_Kofler> Indeed, they promised they'd do it and they didn't.
15:41:42 <rdieter_laptop> was the primary reason
15:41:57 <Kevin_Kofler> That said, had we collected needed patches, they might have been able to do something with them.
15:42:03 <rdieter_laptop> well, "they" = sebas' proposal, but no one followed up on implementing that
15:42:16 <Kevin_Kofler> Dirk's main reason for not doing monolithic tarballs was "I don't know how to do them".
15:42:24 <rdieter_laptop> there's that too
15:42:32 <Kevin_Kofler> If we had researched it, he could have done them.
15:44:34 <rdieter_laptop> Kevin_Kofler: you're welcome to do that research, I suppose, but I'm not sure it'll do much good at this point
15:45:12 <rdieter_laptop> (ie, not sure if upstream will be interested in the results or not...)
15:47:26 <rdieter_laptop> we can (and should) probably delay any official decision until we hear from than, jreznik on the matter
15:47:50 <Kevin_Kofler> Yes.
15:48:02 <rdieter_laptop> but it looks like most currently present (sans Kevin_Kofler) feels kde47 for f15 is not practical, for various reasons.
15:49:35 <rdieter_laptop> i'll think about the possibility of implementing some sort of f15-kde47 side repo (vs the current use of kde-unstable)
15:50:17 <rdieter_laptop> #topic open discussion
15:50:24 <rdieter_laptop> down to our last 5 minutes, any final thoughts?
15:51:44 <rnovacek> rdieter_laptop: would it be problem to create another repo (kde47) at kde-redhat?
15:52:06 <rdieter_laptop> not a problem, just a little work
15:52:44 <rnovacek> that seems to me as a good solution
15:52:51 * Kevin_Kofler worries that such a repo would be held to much lower standard of quality than official updates.
15:53:17 <Kevin_Kofler> (In fact, it's being proposed exactly because we want to put stuff there we consider not good enough for official updates, instead of working on fixing those problems.)
15:53:50 <Kevin_Kofler> It'd also go another step towards making Fedora just yet another conservative distribution.
15:54:09 <Kevin_Kofler> Even the most conservative distros have kde4n side repos.
15:55:14 <rdieter_laptop> I'm hoping this case to be an exception to the rule
15:55:32 <rdieter_laptop> speaking for myself, anyway.
15:55:40 <rdieter_laptop> time's up, gotta run, thanks everyone!
15:55:44 <rdieter_laptop> #endmeeting