[11:02] ok, KDE SIG meeting start, who's present? [11:03] Kevin_Kofler? (svahl, than seem to not be around) [11:03] Present. [11:04] well, a short update from me wrt comaintership between than and I... [11:05] it's been a rocky start, and we have our differences, but we're both adults... [11:05] we're going to (try to) arrange a phone conference call soon, and we can hopefully get on the same page. [11:06] the bigget item of contention was the introduction of kde-settings [11:06] we all had reservations, of course, than more so. [11:07] he ended up reverting a few of my changes, but I didn't think it worth fighting over this late in the game, so let that go. [11:08] end of drama, nothing to see here, move on. :) [11:08] It doesn't look like these IRC meetings are a big success. :-( No Than, no Florian, and today Sebastian is absent too, leaving just us 2. [11:08] questions, comments? (or other topics?) [11:08] well, *this* meeting was supposed to be for than (since he said he couldn't make the later one). [11:08] I don't think we're going to get all of us to communicate at once over a synchronous medium, I'm afraid. [11:09] I'm not sure why than,florian are averse to irc, but I'll try to find out, and see if we can some up with something better. [11:10] than isnt adverse to irc, i see him here all the time [11:10] quote from my last email to them "... What really needs to happen now is finding ways to improve our avenues of communication. Because right now, we stink at it." [11:10] who is "we"? [11:11] we = me, Florian, Than, + a few other @redhat'ers CC'd [11:11] do we need a mailing list or something? [11:11] well, part of our upcoming "conference call" will be my insistence of public forums and transparency. [11:12] Any idea when the Fedora 8 schedule will be decided? [11:12] Because it would be useful to know for the KDE 4 plan. [11:12] let's get F7 out, then we can talk, rattle-cages about that. :) [11:13] Well, the GNOME folks are already importing 2.19.x stuff into the reopened devel CVS and meanwhile we're just sitting there. ;-) [11:13] as far as I'm concerned F8/kde4 line up pretty well, so regardless, we can come up with something to make it work. [11:13] I just hope the GNOME folks won't force a 4-month rushed schedule on us just to "realign" with GNOME's schedule. [11:13] I imported qt4-4.3.0rc1 into devel, does that count? :) [11:14] don't worry... [11:14] [Notify] scop is online (irc.freenode.org). [11:15] I'm glad the KDE4 proposal finally sparked some feedback, discussion. [11:16] couldnt the kdespin have its own schedule? [11:16] XulChris: uh, let's not go there... icky. [11:16] Ugh, I really don't think that would be a good idea. [11:16] ? [11:17] ok well whatever, i dont see any problems with it [11:17] just doesnt make sense to have a kde spin revolve around the GNOME schedule... [11:17] it's not. [11:17] We want one Fedora 8, not GNOME people releasing F8 in 4-5 months and us F8.1 in 5-6 months, that would be a real mess. [11:18] [Notify] |DrJef| is online (irc.freenode.org). [11:19] put that gnome stuff into the updates...that's enough :P [11:20] It would be the opposite: GNOME 2.20.0 is scheduled about a month before KDE 4.0.0. Which would mean we couldn't just push KDE 4.0 through as updates unless we shipped an RC if we end up with a 4-month schedule. [11:21] So I'm completely opposed to that 4-month schedule of course. ;-) Not that I have anything to decide there... [11:21] i cant imagine fedora 8 shipping in 4 months simply to align with gnomes schedule [11:21] The Fedora schedule is pretty simple - release every 6 months, with 3 test releases (each a month apart) before release [11:22] wwoods: I hope it stays at that, especially as it happens to align pretty well with KDE 4.0. :-) [11:22] We'd have about 1 month left between the KDE 4.0 release and the F8 release with that. [11:22] so F8t1 should be in 3 months, F8t2 in 4 months, F8t3 in 5 months, and F8 final 6 months from now.. which would be sometime around Dec. 1 [11:22] well the schedule _always_ slips [11:22] although we might clip the schedule a bit to get it out before the US Thanksgiving holiday, or push it out a bit to be afterward [11:23] so you can add 1 month to that for slippage [11:23] afk 2 min (sorry) [11:23] but the end of November and December are usually a complete wash for US-based folks [11:23] we make it a non-US release then? :> [11:23] The KDE schedule could also slip. So I'm counting without slips for simplicity, if KDE happens to really slip more than Fedora, we have over a month of slack time. [11:24] The KDE 4.0 schedule says: "October 23, 2007: Targeted Release Date" [11:24] isnt kde pretty good about sticking to the schedule? [11:25] although 4.0 is a pretty huge update, so i can see that sliping more than like a 3.x release [11:25] lately yes, bug kde 4 is a big deal. [11:25] ya [11:25] The first milestones have been met. [11:26] What I think really needs to happen is that we need to get a KDE 4 alpha or beta in before F8 test 1. [11:26] We could wait for Beta 1 on June 25, but I don't think it makes sense to wait any longer. [11:27] We want Rawhide testers to find and report bugs. [11:27] getting Beta 1 in before F8t1 is a great idea [11:27] the sooner the better, imo. [11:28] Then let's get the alpha or a snapshot between the alpha and beta 1 in right now? ;-) [11:28] I'm sure we'll all have a better handle on the specifics after akademy (jun 30 - jul 08) [11:28] Kevin_Kofler: yes, and no, we still need to sort out the details of kde3/kde4 co-installs. [11:29] f8 will have both kde3/4? [11:29] and I'm sure Than (and others) would like a say in that too. [11:29] XulChris: likely, yes. [11:29] why both? [11:29] We can't ship all of both KDE 3 and 4 unless we use a custom prefix for one. [11:29] Too many existing kde3 apps may not be ported to kde4 by then. [11:29] There's no way it won't conflict otherwise. [11:29] you're doubling your test / devel workload, though [11:29] that seems.. painful [11:29] We can ship kdelibs and parts of kdebase from KDE 3. [11:30] not to mention taking a lot of room on the media [11:30] And possibly library parts from other modules (kdepim? There are some libs in KDE 3 kdepim, or we wouldn't have kdepimlibs in KDE 4. ;-) ) [11:30] ideally, kde3 can go away, but I don't think that'll happen in the f8 timeframe. I'd love to be wrong. [11:31] It will have to, except for those compat packages. [11:31] compile broken kde apps with static libs :) [11:31] Obviously, you don't have to decide this now, but it would seem much nicer to fully move to KDE4 for F8 [11:31] Kevin's right, we need only the supporting libs, not the full kde3 desktop/environment. [11:31] There's no way we can ship both versions of applications, they don't support switching back and forth between newer and older application versions. [11:32] right, that would be a path to madness [11:32] how will upgrades work from KDE3? are you going to have to mess around with Requires: and Provides: lines to make sure people's F7 machines upgrade right? [11:32] And the executables would also conflict unless we use a custom prefix. [11:32] wwoods: that's a detail yet to be determined. [11:32] just how many broken kde apps are we talking about? [11:32] Stuff like my current KDE4HOME and KDE4DIR hacks would be needed and would be a PITA to maintain, not to mention an FHS violation. [11:33] XulChris: is your definition of broken => "not ported to kde4 yet" ? [11:33] ya [11:33] ok. :) [11:33] compat-kdelibs3 is something upstream actively wants to support, and I think a partial compat-kdebase3 (with only stuff like KControl modules, styles and such) would be possible too. [11:34] considering how long kde4 has been in the works, cant we assume that if an app hasnt been compiled with kde4 libs it never will? [11:34] I think, except for a few exceptions (like possibly Amarok), apps maintained outside the KDE SVN will need compat-kdelibs3 for a while. [11:34] maybe, but we won't know the answer to that for awhile. [11:34] Apps maintained within the KDE SVN are being ported. [11:36] The KDE 4 API is still a moving target, and the results won't be releasable for 5 more months, so I can understand not all developers wanting to move to it right now. [11:36] Apps which use stuff beyond the basic libs, e.g. the KatePart, are particularly painful to port. [11:36] And the bugs still left in the alpha KatePart don't help there. [11:37] so we would also need a kde3-devel to compile these apps [11:37] fwiw, if you folks weren't aware, I've joined (as mostly a lurker atm) the kde-relelease team, so I could theoretically help nudge things. [11:37] So I'd not call apps not using KDE 4 libs "broken" yet. ;-) [11:38] Kevin_Kofler: how attached are you to using compat-* names? (I really really dislike that...) [11:38] XulChris: I'd call it compat-kdelibs3-devel, but the name isn't really important as long as it's there. ;-) [11:38] We could just call it kdelibs3(-devel). [11:39] imo, stick with kdelibs, and use kdelibs4, kdebase4 for the new stuff. [11:39] * XulChris prefers kdelibs3 [11:39] pros: minimizes change for existing packaging. [11:39] Then we'll be stuck with the extra "4" forever like "gtk2" and all that stuff. [11:39] ya [11:40] As for existing packaging, we want to just update all our modules except kdelibs anyway. [11:40] but kdelibs4 is what upstream is using... [11:40] Uh, last I checked they weren't. [11:40] that's what the tarballs were named anyway. [11:41] did they change recently? [11:41] Uh, the one I got is named "kdelibs-3.90.1.tar.bz2". [11:41] ok, nevermind. [11:41] +1 [11:41] kdelibs3,kdelibs(-4.x*) it is then. [11:41] kdebase needs special packaging as a compat KDE 3 package because we need to rip off the executables and possibly some other stuff. [11:42] this possibly hinges a bit on jeremy's compat-* pkg proposal too. [11:42] So we can't use that 1:1 anyway. [11:42] ok. [11:42] The latest version of the proposal only requires the maintainer(s) of the non-compat package to agree. I sure hope Than and you won't block a KDE 3 compat package. ;-) [11:43] no worries, I'm on board. [11:43] What we'd need is a naming guideline though. [11:44] I've seen packages using compat-, packages not using it, compat packages using soname major numbers instead of user-oriented versions and other stuff. [11:44] we should ask around to see what other distros plan on doing, wrt naming. [11:44] But the naming stuff is probably something for FPC, not KDE SIG. ;-) [11:44] jeremy has a proposal coming.... [11:45] it's just another detail to hash out... as long as migration,upgrades are smooth, I'll be happy. [11:45] I'd hate the soname numbering for kdelibs because it would mean the kdelibs3 compat package would be called "kdelibs4" - very confusing! [11:46] I've seen that mess in Kubuntu, it's not pretty. [11:46] right, bad. [11:46] so, the only real options are kdelibs3 (my preference) or compat-kdelibs [11:47] fwiw, I'm planning to get back to that draft as soon as f7 blockers are out of the way and after a few days of relaxed hacking on random stuff ;-) [11:47] jeremy: thanks. [11:47] Or compat-kdelibs3, at least GCC is using that scheme. [11:47] compat-kdelibs-3.5.6-0.3.f8 [11:47] Kevin_Kofler: and as far as your question about schedule is concerned -- that's on the docket for the board to be discussing later today. although a subset of us talked about it some in san diego also [11:48] * rdieter grumbles about missing the official/unofficial meeting/video-taping-party. [11:48] OK. I hope you'll keep KDE 4 in mind when planning the schedule. ;-) [11:49] * XulChris doesnt think schedules should revolve around other projects [11:49] Kevin_Kofler: I'll try not to let it slip my mind when the topic arises. :) [11:49] XulChris: kinda sorta true, but in reality, it's those "other" projects that comprise much of what Fedora is. [11:50] so we can't just ignore them. [11:50] rdieter: unless you use fedora with a headless system [11:50] You'll still need a working kernel then. ;-) [11:50] ya how come we dont revolve around kernels? or X.org? [11:51] schedule involves *all* the major components, esp including xorg, kernel, openoffice, gnome, kde.... [11:52] but as wwoods said, Fedora (tries to) stick to ~6 mos releases. [11:52] yeah, the schedule is, basically, "every 6 months" - it's not really aligned with anything in particular [11:52] wwoods: and thats how it should be [11:53] XulChris: good, because it is. :) [11:53] sometimes it happens to line up with something, and we might shift the schedules a wee bit to accomodate, but that's it [11:54] I'm gonna take hostages if you don't align F8 to kde4 :P [11:54] we'd better start thinking about wrapping this up for the upcoming FPC meeting, any other topics to hit before we quit? [11:54] its actually better to be out of sync because then you have testing and bug fixes go in before you include it [11:54] * rdieter nods, has advantages it does [11:54] there's research that indicates that time-based releases tend to be higher-quality, and it makes people happier when they know about when we'll release [11:54] "when it's done" is rarely a satisfying answer, and it just gives people too much room to waste time [11:56] And it leads to something like Debian stable. ;-) [11:56] let's sooooo not go there. [11:56] exactly [11:56] lol [11:56] various schedules, like the Gnome schedule, exist today because the Red Hat Linux schedule was time based and predictive. [11:57] or something like Windows Vista [11:57] GNOME aligned itself to be able to get the latest/greatest gnome out in a RHL release as that would hit a high number of users. [11:57] if Fedora gets back into a reliable release pattern, we'll see upstreams start to align themselves again. [11:57] good times [11:58] I'd be very happy if our releases happened every May 1 and Nov. 1, or something [11:58] +1 [11:58] wwoods: shift it 3 months so we dont have to worry about holidays [11:58] aug 1 and jan 1 [11:58] Uh, Nov. 1 wouldn't be great this year, it would mean a last-minute scramble to get KDE 4.0 in. [11:58] or feb 1 [11:59] jan 1? yeah, no holidays right before that.. [11:59] heh [11:59] feb 1 ;-) [11:59] aug 1 is national holiday in switzerland ;>