17:33:23 #startmeeting 17:33:23 Meeting started Wed Sep 26 17:33:23 2012 UTC. The chair is tittiatcoke. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:33:23 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:33:40 #meetingtopic Welcome to the openSUSE KDE community IRC meeting! Please wait with other discussion until the meeting is over. This meeting is logged. 17:34:11 Ok. Let's start with the meeting. Who is all present ? 17:34:19 ping 17:34:30 * mrdocs waves 17:34:33 \o 17:34:45 o/ 17:34:51 hi 17:34:55 hi 17:35:16 Topics for tonight's meeting are: 17:35:21 1) Team organization 17:35:33 2) KDE Repositories and our plans for 12.3 17:35:38 3) Status reports 17:35:43 4) Q&A, misc 17:35:55 any other topics that we should discuss ? 17:36:28 Ok. Then lets start with the first topic. 17:36:44 #topic Team organization 17:37:00 einar77_work: ping 17:37:15 cartman: ping 17:37:19 alin: einar77 indicated that he would be a little later 17:37:42 tittiatcoke: italians are always late... 17:37:51 tittiatcoke: joking... 17:38:51 I raised the topic of Team organization to discuss how we as an community team want to continue. I guess that everybody read on the mailinglist that Will can no longer full time support the KDE team as that the Boosters also has to take other tasks. Based on his indication I had the feeling that we seem to be a little lost (so to speak) 17:39:40 Any comments on this / 17:39:41 ? 17:40:31 first we shall know on whom we can really to break things 17:40:35 so packaging mainly needs to be done by community members? 17:40:41 I do not see rabauke 17:41:13 NicoK: That's what I understood 17:41:14 krop is missing too 17:41:28 what does this exactly mean (will not being available), e.g. which tasks have to be done by someone else now? 17:41:36 NicoK: Correct. I had a discussion with Dimstar on the situation in the Gnome team and it is the same situation there. Gnome is community driven at the moment 17:41:58 alin: rabauke couldn't make it. He seems to have only time during the weekend. 17:43:03 we should identify and make a list of the tasks that we need to do now - also it seems that there are some scripts out there to ease packaging in case a new version comes out - it wuold be nice to have them available somewhere 17:43:11 to avoid double work 17:43:25 A lot is already done by community members. Look at the KR49 repo. A perfect example of community work. Also KUSC is community driven. 17:44:25 One of the tasks that needs to be handled is the coordination of the team efforts, leading/organization the team meetings and sometimes to make a final decision on something 17:44:33 tittiatcoke: I think we shall nominate one person for each repo 17:44:41 tittiatcoke: i see you in the same place as Dimstar - our benevolent overlord :) 17:44:50 teh things i can think of is packaging, bug assignees and support (in a broad sense) and documentation 17:45:00 mrdocs: Lol :-) but I am not sure if the whole team sees it also that way 17:46:12 it's a meritocracy.. whoever will package stuff and fix bugs in KDF automatically becomes an/the overlord 17:46:24 true 17:47:22 cb400f: true. But still there are some things that goes beyond just packaging and fixing stuff 17:47:55 I guess the persons who can tell us are the ones who did the job before 17:48:27 Which is Bille in this case :-) 17:49:26 I don't think we have to sort it out tonight, but I wanted to catch your thoughts on this subject and to see if the team is ready to become completely community-driven :-) 17:49:43 he will be able to read this later - might be an idea to create a list of things so far done by the boosters team - for KDE of course 17:50:13 tittiatcoke: I think we do not have a big choice in that - the alternative is to fail I guess 17:50:13 Yes. I will ask him to put some things in an email so that we can see what needs to be done and how to organize this. 17:50:30 skunze1: :-) 17:51:41 maybe don't just put it into an email but also the wiki - or at least we need to sum it up in the wiki at some point... 17:51:57 the wiki is also a point 17:52:08 Another item in this category is the indication that alin did. We had the same thing in the past, but the old masters disappeared slowly. I think it would be good to nominate a responsible person for each of the repositories we have. (In my opinion this would be KRxy, KDS, KDF, KUSC). 17:52:35 NicoK: Ok. I will create a wiki page for this, where we can list the tasks we see and put also our comments there. 17:52:45 it should be clear then what this person is supposed to do 17:53:11 here's an old list of the general maintainers' responsibilities: http://en.opensuse.org/openSUSE:KDE_Maintainers_Cheat_Sheet 17:54:05 That looks like a good starting point 17:54:21 indeed 17:54:49 dont forget if Bille is busy I can access private bugs now 17:55:01 noted :-) 17:55:11 L3 Bugs - we need to cut that out or find a solution - I think no community member has access to those 17:55:21 i'm on leave for the next 2 weeks btw 17:55:38 skunze1: the short term solution is I negitate :) 17:55:43 negotiate 17:55:52 Bille: btw, congrats :-) 17:55:53 skunze1: yep, and we're even trying to kick those out of the openSUSE Team's task list. but it needs kde maintenance skills in another team 17:55:57 mrdocs: thanks 17:56:18 and we should do this without scoring the own goal of getting SLE to drop all kde packages :) 17:56:49 true :) 17:56:51 Bille: you mean no more KDE in SLE ? 17:56:52 :) 17:56:59 mrdocs: yes 17:56:59 late late late! 17:57:08 Is the meeting still ongoing? 17:57:16 couldn't make any faster than this 17:57:25 einar77: we're still at the first topic ;) 17:57:31 einar77: Yup. We are at the same topic :-) Team organization 17:57:35 Bille: then the question is can we maintain SLE build then ? 17:57:52 even if unoffical builds 17:58:05 mrdocs: *we* can certainly build vs sle releases 17:58:12 I mean if Gnome is in the same situation - SLE will not drop Gnome and KDE 17:58:17 mrdocs: anyway that is only one bad possible outcome i want to avoid 17:58:23 it hasn't happened 17:58:51 tittiatcoke: before we decide on reps for kde repos maybe we shall first decide on repos 17:59:07 and it would be a dishonest outcome given that there is customer demand for kde 17:59:14 anyway, not really on-topic 17:59:19 true 17:59:33 Bille: Any comments/hints from your side on how we should organize ourselves as a team 18:00:02 tittiatcoke: not too many people on each responsibility, so people don't assume someone else will do a task 18:00:32 alin: I would like to have first an alignment if we need such persons per repo. Then later when we have the repo's we can assign a person if required 18:00:34 Bille: Ok. 18:01:43 I'd say, have at least 2 persons per repo for cases of unavailability 18:01:45 in maintenance i'm out - I'm neither a developer nor packager (yet) and it will take a while to reach an level to take on task like this 18:02:16 NicoK: +1 18:03:51 NicoK: That would be good. I see the tasks of such person(s) to review/accept the SR's, be the main contact for that repo and in the case of KRxy when to update to a newer version. 18:04:28 and of course to coordinate the work in that repo. 18:05:01 not to mention that different repos have different levels of maintenance in my view 18:05:17 einar77: can you elaborate a little more on that ? 18:05:22 if main development is happening only in KDF though - then the other repo's "gurus" don't have much to do... so basically we need someone for KDF 18:05:50 tittiatcoke: a KDF needs in my view more work than a KRxy 18:05:59 not to say that the latter is no work 18:06:06 quite the opposite 18:06:24 I agree, but KRxy would have monthly updates, etc. And I think that KRxy is much more exposed to the outside world than KDF 18:06:48 hm, I gueess you're right 18:07:16 but KRxy should only link to KDF versions, so imho this means, after/immediately before a new release: get it building in KDF, then link it to KRxy 18:07:51 the only exception to that was the period of the 12.2 freeze for KDF recently 18:08:15 can we define x? 18:08:19 Correct, but the question would be if we have 4.9.3 in KR49 and KDF is jumping from 4.9.3 to 4.10 beta, would we no longer update KR49 to 4.9.4 when that comes ? 18:08:38 let us say.. we maintain x=current and x-1 18:08:47 the rest people are on their own? 18:09:01 tittiatcoke: I would keeep the Rxy repos until upstream EOLs 18:09:03 anyway, we need to keep (double) work down as much as possible; concentrating on one repo alone is already much to do 18:09:10 alin: So you mean we would support KR49 and KR48 ? 18:09:20 for KDS the question wouldbe bugfixes for the 2 year maintenanceperiod 18:09:30 As upstream, I would say there's little gain unless it's KDS 18:09:39 KDF only ever got RC's - and after an RC, normally no new minor release of the previous version comes out - 4.8.5 is the only exception I know of 18:09:42 tittiatcoke: KDS is the one that somehow is related with sled? 18:09:58 alin: I am not sure. Bille ^^ 18:10:03 alin: no 18:10:22 nope KDS is the KDE Version a release was shipped with 18:10:24 it is the devel project for updates for the last relaease version of opensuse 18:10:37 alin: no 18:10:42 then what is the reason of a KDS? 18:10:46 as far as I understood KDS was created in the past where we didn't had the current maintenance support 18:11:13 KDS should build updates that then could be incorporated in the latest openSUSE official release. 18:11:21 then the discussion is for each repo against what base we build? 18:11:45 tittiatcoke: can't that be done in the official update repo of the oss? 18:11:46 KDS should only build against the release for which it was shipped 18:11:50 alin: you are going to fast :-) 18:12:16 lets start from the top then - KDF :) 18:12:47 before we jump to the repository topic, can we close the first topic. I would suggest that we all look at the link that Bille provided and add our comments there. Then in the next meeting we can discuss changes and responsibility assignments. Everybody ok ? 18:12:56 skunze1: just a sec :-) 18:13:10 tittiatcoke: ok 18:13:14 tittiatcoke: ok 18:13:43 #action everyone Check the Team tasklist on http://en.opensuse.org/openSUSE:KDE_Maintainers_Cheat_Sheet 18:14:18 #topic KDE Repositories What do we want to achieve with which repo 18:14:29 Ok. Now let's have the big discussion :-) 18:14:43 Let's start with the number one on the list. KDE:Distro:Stable. 18:14:58 tittiatcoke: I propose to ax it 18:15:01 axe it 18:15:14 I personally don't have any plans with it; nor do I see its use now that we have KRxy 18:15:29 Currently that one contains the KDE release shipped with 12.2 and was intended to provide KDE minor updates as that there was no maintenance workflow yet. 18:15:41 if there are different ways to prepare patches, it has no use 18:15:51 (different _better_ ways) 18:16:05 ship updates from the according KRxy 18:16:24 NicoK: probably the best 18:16:34 KRxy is still links from KDF no? 18:16:37 tittiatcoke: i'd dispute that purpose for KDS 18:16:55 cb400f: only the when x=c 18:16:59 current 18:17:10 Bille: Ok.Can you help out on it's purpose ? 18:17:13 as that use was removed by KRxy and osc maintenance 18:17:18 cb400f: fixed links, i.e. it does not always point to the latest version in KDF 18:17:39 Bille: Ok, but in the past when we didn't had KRxy and osc maintenance, it was had that purpose ? 18:17:46 * tittiatcoke removes was 18:18:01 say 12.2 has amarok 2.5 ... krxy has amarok 2.6.. how do prepare a patch for amarok in KRxy? 18:18:08 the purpose it still has is to test updates to the distro release KDE 18:18:27 there's the test-update repo though 18:18:35 the difference to KRxy is that you can leave it publish-enabled without affecting many users 18:19:06 Bille: isn't that, what the test-update repo is there for? 18:19:08 cb400f: then each revision has got to go through the maintenance team 18:19:27 ah, not good 18:20:21 it also serves to define the set of packages that we maintain for the distro release 18:20:21 Bille: Do we have examples from the past where we used KDS ? 18:20:22 so if I understand taht correctly KDS contains the shipped state + Updates fro KDE since shipment but no new Versionsupdates 18:21:00 otherwise how do you tell which packages to update and test? querying with osc maintainer, looking at the patterns, etc 18:21:16 skunze1: not quite, we have done some .z updates in the patst 18:21:37 tittiatcoke: every maintenance update to KDE went through there 18:21:37 only 1 or 2 iirc 18:21:49 ie testing and adding patches 18:22:21 do we have the manpower to maintain that? 18:22:29 IMHO the question is, do we want to ship updates to KDE SC regulrarly then we could use KRxy instead of KDS 18:22:31 that should be the question... 18:22:39 Bille: But that would mean that we should setup multiple KDS repo's. How else can we support the KDE version of 12.1 with the current KDS ? 18:22:43 ctrippe: that's a question and an answer 18:22:59 tittiatcoke: in practise we only tried hard to support the previous release 18:23:13 anything else was supported via osc branches 18:23:37 since we never had the manpower to offer perfect support for all maintained releases 18:24:19 Ok. So the question would be more if we want to ship updates to KDE SC regurlary to our users. 18:24:43 tittiatcoke: as in point releases? 18:24:50 Correct. 18:25:04 NicoK: if we, and the opensuse project (via its maintenance team) accept to ship all .z point releases as maintenance updates, you could use KRxy for that 18:25:08 Although there may be regression, I would encourage that 18:25:11 regressions 18:25:25 Bille: +1 18:25:30 einar77: +1 18:25:32 as I said, I happen to see quite often people in the forums that have issues with version X while X.1 has it fixed 18:25:37 the drawback is you risk pissing off regular KRxy users while you are testing yet another unproven patch from the kdepim or nepomuk teams 18:25:52 I'd prefer not to have nepomuk and akonadi blow up in my face every month 18:25:56 or plasma 18:25:59 this is probably the most tested repo as (and I think, I'm not only talking about myself) we developers don't use KDS... 18:26:12 and what about non-SC stuff? 18:26:21 cb400f: toe be honest, the only big issue with 4.9.0 -> 4.9.1 was the kwin regression 18:26:45 does that also mean pushing feature releases of digikam and amarok etc. as official updates? 18:26:50 and we resolved that in the packages quite quickly... 18:26:57 anyway, thats all i have to add KDS, and i've said it already on the list 18:27:06 cb400f: I guess we would have KUA for that one. 18:27:08 if we ship x.y+.z updates regularily through online updates what do we do with the users that do not want to upgrade to a newer KDE in a release - in that case we would not fix bugs - or as a alternative - we could offer a block for KDE Updates in apper ? 18:27:17 before shipping KRxy as an update, we should probably let 2 weeks pass... 18:27:36 cb400f: i wouldn't conflate non sc app version update policy with whether to use KDS or osc branches or KRxy for maintenance update development 18:27:36 NicoK: +1 18:27:41 cb400f: different discussion... 18:27:50 agreed, non SC stuff is another matter entirely 18:27:59 NicoK: +1 18:28:12 (especially since some non SC stuff is... exotic in the way they do things) 18:28:42 NicoK: how would you prefer to test inter-point release patches for critical bugs that show up after you've published? osc branch? 18:29:21 they'd be tested in kdf I guess? 18:29:37 Bille: first testing in KDF (since this is the main development project), then (if successful), update link in KRxy 18:29:52 before KDF probably a osc branch 18:29:59 that's what I did in the past 18:30:02 cb400f: what if kdf is 4.10 and the last opensuse release had 4.9? 18:30:04 if it affects only one package 18:30:44 Bille: when 4.10 lands KDF, there shouldn't be any extra point releases of 4.9 18:31:13 anyway, if KDF and KR49 are decoupled, packages are copied to KR49 and thus we can test 49 specific patches there 18:31:36 the preiod where this is necessary (and we really have 2 dev branches) should be rather short 18:31:41 *period 18:32:32 Ok. If I conclude on what has been said, then the KDE team would like very much to provide point releases throught the standard update process of an openSUSE release.And the preferred way of providing these updates is to utilize the KRxy reo for this. 18:32:44 agreed 18:32:51 +1 18:33:08 most users won't be able to install them anyway thanks to pk/zypp-pk >:-) 18:33:16 cynic :) 18:33:23 Bille: Who in the maintenance team should be contact for this ? 18:33:29 sounds good for me - but I predict a shitstorm on the mailinglist 18:33:53 tittiatcoke: one more thing...what versions we build against? 18:34:04 I also agree and fear the cb400f might be right :( 18:34:07 skunze1: maybe on the opensuse@opensuse.org list... the opensuse-kde only has version whores 18:34:13 do we offer the last kdexy for the stone age oss? 18:34:37 tittiatcoke: maintenance@opensuse.org 18:34:53 cb400f: ctrippe not if they remove packagekit 18:35:12 #action tittiatcoke contact the maintenance team to discuss the possiblity to provide KDE point releases throught the maintenance workflow 18:35:14 the best would be to do it for all supported releases if Evergreen wants to keep a version going I doubt that they keep updating the KDE Version then 18:35:33 alin: sure, that's the problem :) 18:35:48 skunze1: the problem is that new kde means new base libs 18:35:59 for peoply not wanting to update, "zypper al" should be made available more prominently in the updaters, e.g. in YOU, it should block the patch, not the packages... 18:36:07 alin: if it is clear that the repo is frozen without updates and maintenance - then why not 18:36:09 skunze1: and you end up forcing them to update packages they do not want... a lot of work for us 18:36:24 then only the space on the server is limiting 18:36:40 skunze1: kr49 shall we build it against 12.1? 18:36:59 skunze1: or only 12.2 and factory... maybe troubleweed? 18:37:23 alin: I only would decide this on a case by case basis. If it can be done with reasonable work I am all for it otherwise don't build for the oldest oS release 18:37:50 I would propose to build the KRxy releases to the current openSUSE release and the release -1. 18:38:01 alin: difficult 18:38:02 speaking of version updates, I have some thoughts but I'd rather put them at the end of the topics unless there's something in the queue to discuss 18:38:02 ctrippe: reasonable for you and I means one thing... always you will find people who think is reasonable to run 49 on 11.4 18:38:51 alin: what would be your proposal for KR49 ? 18:38:59 alin: sure, but if we don't provide it they have to live with it. 18:39:51 tittiatcoke: if we agree to ship point releases as updates, there won't be anything to do for 12.2 anyway since 4.8.5 was the last in the 4.8 series... 18:39:53 tumbleweed should not really concern us - as it is only a link anyway 18:40:25 tittiatcoke: I agree with your KR49 proposal (although I have no idea how its state for 11.4 is). 18:40:36 NicoK: you would propose to only update .z releases but not .y 18:40:41 its one option 18:41:11 skunze1: You are thinking of shipping KDE 4.9.1 to the 12.2 users as an update ? 18:41:13 that's how I read the discussion - me personally, I'll go for the latest release anyway :P 18:41:41 but the f.e we probably will skip some releases (like there will never be an official release with 4.9 18:41:50 me to personally 18:42:26 tittiatcoke: it would be a major break from the past 18:42:48 In my opinion if people want to update to a newer KDE version, then they either should switch to tumbleweed or utilize the newer KRxy repo. (in this case KR49). 18:43:00 tittiatcoke: I'm on the fence, as I said earlier 18:43:09 but in the end what do we save when we cut KDS but maintain a lot of KDRx.y#s 18:43:13 especially wrt point updates 18:43:43 mine too.. the point releases are bad enough, major feature upgrades is madness of fedoraesque proportions 18:43:46 tittiatcoke: +1 18:43:49 we don't maintain a lot of KRxy - only the latest! (same as with KDS - there was only one) 18:44:28 If we have a sudden bug in the KDE version shipped with 12.1, then KDS wouldn't help us here either. 18:45:18 tittiatcoke: but we have a chance of fixing it in the appropriate KRxy if someone put the patch there... 18:45:21 NicoK: weoffer on the server KDR 4.7 for 11.4 , 4.8 for 11.4/12.1/12.2 and 4.9 for 11.4712.1/12.2 if I'm not mistaken - some might be only mirrored but they are there 18:45:42 tittiatcoke: +yes, but we have... 18:45:48 NicoK: Correct, :-) 18:45:55 cb400f: actually I am of the opposite view 18:46:09 from my user support (distro-agnostic) PoV 18:46:32 einar77: user support can be a pain :) 18:46:44 einar77: But I would like to prevent that we are creating a kind of KDE tumbleweed :-) 18:46:57 sorry, just back. so we supposed cut KDS and do maintenance update from KRxy? 18:47:04 skunze1: they are there, but after having polished their latest updates, they barely ever rebuild and thus contain a stable state without additional effort necessary for the old KRxys 18:47:07 maxlin: That is the current proposal 18:47:27 NicoK: ok - as I said i'm not a packager 18:47:30 tittiatcoke: agreed as well 18:47:46 then how about the rest of applications, ex. ktorrent, etc 18:47:56 if they need a update? 18:48:06 Do we do this, dropping KDS, already now, or do we leave it for 12.2? 18:48:17 currentlywe have the updatedapps repo? 18:48:25 So I would propose to build KR47 for 11.4, KR48 for 11.4/12.1/12.2 and KR49 for 12.1/12.2. Anyway in a few months we would drop the overall support for 11.4 18:48:58 maxlin: If there are bugfixes, then we provide them through the normal maintenance workflow. Otherwise we have KUA for this 18:49:02 skunze1: KUA is non-SC version upgrades ... not patches for existing versions in the released distro 18:49:13 maxlin: Until now we only discussed the KDE SC, how this effects updates for e.g. amarok has to follow 18:49:27 cb400f: ok 18:49:29 ok 18:49:47 * Bille is going to bed 18:49:53 2 hours sleep in last 27 18:49:57 Bille: Good night and thanks 18:50:02 i look forward to the minutes! 18:50:15 Bille: good night 18:51:02 Bille: good night (and congrats as I didn't say this earlier) 18:51:06 tittiatcoke: me... current and factory 18:51:49 tittiatcoke: if people want to use new versions update... if not remain with the maximum offered by some previous KRxx 18:52:13 thx 18:52:13 alin: why would we build KR49 against factory ? Do we not have KDF for that 18:52:40 tittiatcoke: true 18:53:05 indeed 18:53:20 +1 18:53:52 tittiatcoke: I go to grub something to munch... but I shall be back for our goals 18:54:01 ok 18:55:23 let's continue though - we don't have all night ;) 18:55:27 So we agree on my proposal ? 18:56:03 KR47 for 11.4, KR48 for 11.4/12.1/12.2 and KR49 for 12.1/12.2? 18:56:08 Yup 18:56:21 and additionally KDF for 12.1, 12.2, Factory? 18:56:31 +1 18:56:36 NicoK: I believe KDF should only be build for Factory and 12.2 18:56:39 what would be the point of pushing 4.9 to 12.2? 18:56:55 it's extra work, and with zero benefit to anyone 18:57:01 cb400f: Just to provide a repo for those 12.2 that would like to update 18:57:09 tittiatcoke: fine with me 18:57:26 ah, crap, I misunderstood.. thought it was about official updates 18:57:28 tittiatcoke: restricting it to 12.2 and Factory also reduces build load 18:57:31 carry on, nothing to see 18:57:40 :-) 18:57:56 fine with me 18:58:22 next? 18:58:27 Ok. I assume this is agreed then 18:58:56 #info KR47 builds for 11.4, KR48 builds for 11.4/12.1/12.2, KR49 build for 12.1/12.2 and KDF builds for 12.2/Factory 18:59:51 sounds good 19:00:19 #topic development workflow for new opensuse releases 19:01:17 Ok. Next topic 19:01:35 * tigerfoot arrive only now, what a backlog ... congrats guys :-) 19:02:10 The current development workflow is to have the newer KDE release (snapshots) in KUSC, then when it reaches RC level to move it to KDF and then move it to Factory. 19:02:31 I guess we should add that once it moves to Factory we also should start setting up the KRxy repo for it. 19:02:46 Based on what we discussed I do not see a reason to change this. 19:03:02 +1 19:03:16 +1 19:03:18 so KRxy repo just before the release with the final version in it? 19:03:32 or are you talking about setting it up with the RCs, too? 19:03:46 I'd go for the first... 19:03:47 and especially if the publish build is looked down until the release is real 19:04:23 publish will be disabled before the release in KRxy as well... 19:04:36 NicoK: +1 19:04:45 NicoK: My understanding would be only before the final version 19:05:10 ok (@final version only) 19:05:21 +1 19:06:05 in general, this means that KRxy will probably be delayed a bit in publishing the latest release as it needs to be fully building in KDF first before we link it in KRxy 19:06:35 so depending on how long we need to polish in KDF, KRxy may not have build and published right at release day - hopefully KDF will though 19:06:45 #info Development workflow remains the same KUSC -> KDF (rc's) -> Factory. KRxy repo will be setup just before the openSUSE release. 19:07:13 tittiatcoke: KRxy repo will be setup just before the KDE xy release 19:07:17 noe openSUSE 19:07:24 *not 19:07:27 Ok 19:07:29 yeah 19:07:38 #info Development workflow remains the same KUSC -> KDF (rc's) -> Factory. KRxy repo will be setup just before the KDE release 19:07:46 Will correct that in the minutes :-) 19:08:24 #topic Targetted KDE release for 12.3 19:08:40 tittiatcoke: also this is just the development workflow for new major KDE releases - not minor like 4.9.2 19:08:41 Maybe this is an open door, but are we targetting to release 12.3 with KDE 4.10 or 4.9.x ? 19:08:50 NicoK: Correct 19:09:21 first question - when will 12.3 be released? 19:09:25 assuming 12.3 is released in March, 4.10 19:09:45 but we don't know that.. only it's pretty certain it will not be _before_ march 19:09:52 if march I would target 4.10 - depending on when the freeze is 19:10:05 since we'd like to ship point releases as updates now, we could go with 4.10, right? 19:10:09 the freeze would be about 2 months before.. so it would be tight 19:10:17 mrdocs: Are you aware of any timing for 12.3 ? 19:10:41 exactly like 11.4 which shipped in march 2011 with nice and byggy 4.6.0 19:10:56 March would be the regular release of 12.3 - not counting the 12.2 delay - so it would be 6month after 12.2 19:11:01 good evening gentlemen! :) 19:11:04 * tigerfoot look around in rumor thread .... look the bird's fligth and say March is good :-) 19:11:18 05/03/2012: 4.10.1 release - if that's around the same time of 12.3, we could immediately ship that, too 19:11:35 tigerfoot: this question should to coolo :) 19:11:35 I can keep up to speed with upstream's changed 19:11:35 tigerfoot: evil forces are fighting for the 12 year cycle 19:11:37 changes 19:11:41 like we did the 4.8.5 this time 19:11:44 tittiatcoke: this question should to coolo :) 19:11:48 tigerfoot: sorry 19:11:55 (of course because their real agenda is to promote tumbleweed over opensuse) 19:11:58 I'm keeping watch of many things upstream 19:12:00 maxlin: no problems :-) 19:12:11 maxlin: Will check tomorrow with coolo 19:12:26 what I can tell you already for 4.10 19:12:36 if we get to a 12 months cycle - someone would always be screwed - either GNOME or KDE 19:12:38 tittiatcoke: no idea on timing for 12.3, the sum up at the summit was 12.2 delay was an exception 19:12:46 so the would be the worst possible option 19:12:49 I'd go for shipping 4.10 and those that want a more stable KDE release wait until 4.10.1 or .2 has been shipped. 19:12:56 #action tittiatcoke check with coolo the release calendar for 12.3 and when the freeze would be 19:12:57 and no one at the sumiit mentioned changing our schedule 19:12:58 september would also be a quite sucky release time for 12 month releases imho 19:13:08 rabauke: bear in mind that a lot of new things might introduce regressions 19:13:12 with the summer holidays and such 19:13:30 (I'm seeing some atm, not saying that they won't be fixed, but these aren't minor bugs) 19:13:35 I guess that with 12.3 we would have the first option to release utilize the new maintenance updates as that we would have then a release that ships either the .0 or .1 relase 19:13:35 einar77: that's why people can wait until after the .0 release. assuming .1 etc. are shipped. 19:13:56 cartman can also be pinged about the release... we now have a real review team :) 19:14:12 einar77: and 12.3 as such is "a lot of new things". AFAIK kdelibs is "frozen" anyway until KDE5. 19:14:13 mrdocs: Ok. 19:14:20 rabauke: plasmoids -> QML 19:14:37 often the transition is not painless 19:14:39 also there'd be about 6 weeks after 12.3 freeze to backport patches from upstream.. so it wouldn't be completely fresh, vanilla 4.10 19:14:46 einar77: could they be worst than actually ... 19:14:57 on the topic of patches 19:14:59 sure, but as I said, shipping .0 and minor releases until .5 will give users the choice when to change their distro. 19:15:17 I was thinking that perhaps there should be a way to keep a lits of things we might want in 19:15:43 einar77: what do you mean with things we might want in ? 19:15:52 tittiatcoke: example in case is udisks2 19:15:54 for example 19:16:05