[01:32] hey [01:32] anyone actually here ?? [03:22] shadeslayer: I finally read The Fault in Our Stars [03:23] loved it [05:42] Hey guys. I'm new to Linux/Kubuntu but would like to get involved with the community here [06:30] IAmLycan: welcome! talk to valorie, she handles documentation and stuff, which can be a really good way to get a feel [06:30] She's actually the one who directed me here! [06:31] :D [06:31] IAmLycan: what are you interested to do? [06:31] I'm trying to get into web development [06:32] jussi: I got lots of requests for stickers, and lots of admiration for the new shirt [06:32] valorie: :) [06:32] at linuxfest northwest [06:32] IAmLycan: ahh then speak to ovidiu-florin - he handles a lt of the web page stuff :) [06:32] valorie: I hope you directed people to the shirt website :) [06:33] I didn't bring scissors to cut them apart, but used the lil scissors on my swiss army knife [06:33] of course! [06:48] Good morning. [06:51] valorie: is it even possible to not love tfios? ;) [06:51] or any john green book really [06:53] Finding Alaska is the first one i read [06:53] this was the second [08:31] hm, is this known to you? https://bugs.kde.org/show_bug.cgi?id=334053 (Kubuntu 14.04) [08:31] KDE bug 334053 in general "Error Message after creating Projects: Can't load KDevCMakeManager" [Major,Unconfirmed] [08:36] kfunk: not known to me [08:38] * Riddell adds to todo but no promises for early attention [08:51] bug 807386 [08:51] bug 807386 in kdevelop (Ubuntu) "CMake should be a required dependency." [Medium,Triaged] https://launchpad.net/bugs/807386 [08:51] ScottK: do you have a thought on SRUing a fix for that? or, actually my question is: do you think the relationship should be recommends or depends? [08:51] Riddell: ^ [08:52] shadeslayer: are we SRUing ktp? [08:53] apachelogger: it should be recommends as it's perfectly possible to use kdevelop with say python that doesn't use cmake [08:55] but then the cmake based templates will throw an error on creating a new project when cmake is not present [08:55] perhaps we should revise the package structure there [08:56] iff there was a devcmakemanager packager that one would clearly depend on cmake, and kdevelop would clearly recommend devcmakemanager [08:57] kfunk: got an opinion? [08:59] hm... [09:00] kfunk: should kdevelop package depend on cmake or should it be an optional dependency which still brings in cmake by default? [09:01] yeah, i've understood the problem. but afaik KDevelop shouldn't error out like that if cmake is missing. I'm not sure it's related to that particular bug you mentioned above. [09:01] let me investigate that a bit more later, I don't really have time atm. [09:01] thanks for the hints so far [09:03] ovidiu-florin: ping, how's the new website coming along? [09:30] apachelogger: already done [09:30] Waiting approval [09:31] shadeslayer: where are the tracking bugs though? [09:59] apachelogger: https://bugs.launchpad.net/ubuntu/+source/meta-kde-telepathy/+bug/1313611 [09:59] Launchpad bug 1313611 in meta-kde-telepathy (Ubuntu Utopic) "[MRE] Please update meta-kde-telepathy to 0.8.1" [Undecided,New] [10:03] fun story: meta-kde-telepathy is not subbed to by kubuntu-bugs [10:03] .......... [10:03] shadeslayer: please sub kubuntu-bugs [10:03] :( [10:03] pl [10:03] ok [10:04] can't [10:04] not a admin [10:05] Riddell: https://launchpad.net/ubuntu/+source/meta-kde-telepathy/+subscribe [10:05] Riddell: plz subscribe kubuntu-bugs [10:05] shadeslayer: voila [10:05] thx <3 [10:05] "The Kubuntu Bugs team will now receive an e-mail each time someone reports or changes a public bug in "meta-kde-telepathy in Ubuntu"." [10:06] could someone verify bug 1308820 and bug 1275243 [10:06] bug 1308820 in homerun (Ubuntu Trusty) "[SRU] Update homerun to 1.2.3" [Undecided,Fix committed] https://launchpad.net/bugs/1308820 [10:06] bug 1275243 in homerun (Ubuntu Trusty) "plasma-widget-homerun-kicker package should depend on plasma-widget-homerun" [Undecided,Fix committed] https://launchpad.net/bugs/1275243 [10:06] shadeslayer: http://markmail.org/message/sfurehuwtenmfok4 [10:07] apachelogger: yes, I know [10:07] I do read my email you know [10:07] "If you are regularly uploading new packages and are not admin of kubuntu-bugs please poke me or Riddell to promote you." [10:07] Riddell: apachelogger plz do promotery to ~rohangarg so that I may be able to do stuff [10:08] done [10:08] thank you [10:08] apachelogger: I agree that recommends is correct for kdevelop/cmake. [10:09] bug 1314119 much test case :O [10:09] bug 1314119 in pam-kwallet (Ubuntu Utopic) "/usr/sbin/lightdm:11:__GI__IO_fwrite:createNewSalt:kwallet_hash:pam_sm_authenticate:_pam_dispatch_aux" [Undecided,New] https://launchpad.net/bugs/1314119 [10:09] ScottK: ok [10:09] "Rohan Garg 2010-04-06 2014-06-14 Administrator" [10:10] shadeslayer: seems you are already ↑ [10:11] apachelogger: I am possibly running a fix for that [10:13] time for some daft punk you say? [10:13] I agree [10:14] https://www.youtube.com/watch?v=FGBhQbmPwH8 [10:15] * Riddell turns off Michael Nyman in favour of daft punk [10:18] shadeslayer: better be testing that http://people.ubuntu.com/~apachelogger/tmp/pam-kwallet_0.0~git20140410-0ubuntu2.1_amd64.deb [10:18] apachelogger: I have it compiled locally [10:18] shadeslayer: better be testing that http://people.ubuntu.com/~apachelogger/tmp/pam-kwallet_0.0~git20140410-0ubuntu2.1_amd64.deb [10:18] that is not a gitty shot [10:18] oh? [10:18] git contains unrelated plunder [10:19] Alex wanted to release the git snapshot I think [10:19] I'd really not mess around with patching pam kwallet tbh :P [10:20] if git didn't contain unrelated cmake foo I'd almost agree [10:21] No MRE for pam-kwallet, so I'm with apachelogger . [10:21] apachelogger: plz run by afiestas [10:22] it's not something I'd update without upstream approval [10:23] May as well get used to it. Once we're on KF5, there's no upstream support anyway. [10:23] (see the mail to packagers on their release methodology) [10:25] ScottK: I think you can blame shadeslayer for that btw [10:25] it's not like we did not have a packager on site ;) [10:25] ScottK: I don't think having a 1 month release cycle with no bug fix branch equals no support [10:26] the idea was that the first few months will most likely get a higher number of bug reports, and it'll be better to release frequently with a few features and many bug fixes [10:27] shadeslayer: Right, so once we hit feature freeze, we're done. [10:27] it does mean no support. unless a distribution either adjusts policy to push potential-feature-releases in stable releases or adjust the distribution release cadence to match upstream [10:27] No more updates from upstream. [10:27] ScottK: not quite, it'd be nice to get a exception to that for KF5 [10:27] shadeslayer: No way. [10:28] "Hey, upstream is pushing random features with every release now" is the opposite of what can get an exception. [10:28] ^^ [10:29] Also, then since there's no bug fix releases, those fixes that come in the first month, we never get except before feature freeze unless we cherrypick by hand. [10:30] ScottK: fwiw, firefox does the same though [10:30] ^^ [10:30] granted though, firefox is not a development platform [10:30] apachelogger: Firefox and chromium are exceptions only because they are big enough that there's no choice. [10:30] if firefox breaks, firefox is broken, if a framework breaks potentially hundreds of applications break [10:31] apachelogger: and then it will be fixed within 1 month ( or less if we cherry pick ) [10:31] Also every Firefox/Chromium release is a security release, so have to move forward. [10:31] I dunno about you, but if the better part of my desktop is broken for a month I'll probably go look elsewhere [10:31] shadeslayer: No. Once we hit FF, we NEVER get the update without a cherrypick. [10:32] ScottK: unless we modify the policy and follow something like what firefox and chrome do [10:32] shadeslayer: Won't happen. [10:32] [12:27] it does mean no support. unless a distribution either adjusts policy to push potential-feature-releases in stable releases or adjust the distribution release cadence to match upstream [10:32] It's not our policy. It's the tech board's. [10:33] The only comparable case I can think of is clamav, but the rationale there is that it loses effectiveness over time against the threat, so standing still isn't an option. [10:33] we can polish this turd all day long at the end it will still mean that a monthly feature release policy upstream means that distributions either must not go into feature freeze or not honor their feature freeze or also do monthly releases [10:34] in any other scenario there is no upstream backing [10:34] Yep and I don't see either of those being feasible for us. [10:35] So I find my level of caring about how much upstream likes what we have to do to get stuff working dropping significantly. [10:35] well, I always thought that using an LTS foundation and simply have a rolling KDE software stack ontop of that would be aboon [10:35] There's not a good way to do that though (as "official" releases). [10:36] alas, since there's no policy upstream WRT how new dependencies can be that might not work out when workspace suddenly decides they need latest and greatest wayland [10:36] * ScottK needs to go $work. Chat with you later. Yep. [10:38] so even if the tech board policy makes no sense for us, we still have to follow it? [10:39] that's just screwed up :/ [10:39] ScottK: I am sure a way could be devised. The thing is, if we do not find a way to adapt to a one month release cycle in some way we might just as well stop doing it altogether because if we release 3 month old frameworks and then expect the user to use that for up to 9 months we are not being the greatest KDE distribution there can be. [10:41] Equally even if we excepted frameworks from feature freeze and stable release policy, their CI does not run Kubuntu, it also does not do package builds. So the fact that upstream intends to have 100% autotest coverage and CI does give us absolutely nothing from a platform alignment POV [10:41] shadeslayer: we have to follow it if we want to be an official ubuntu flavor [10:42] Again, we are not talking about isolated exceptions a la firefox here. We'd have to pretty much exempt the entire kubuntu package set from any sort of feature freeze. [10:44] So, while we would still release on the same day as the other flavors, we would not follow the release schedule or the stable updates policy or anything really. At that point the package set would be fundamentally different from the rest of the ubuntu archive in terms of policy etc. [10:44] apachelogger: I thought about it and concluded that we have to just assume KF5 doesn't matter that much. As long as we deliver Plasma Desktop and Applications on a schedule then I think we're OK. If Plasma did the same kind of thing, it'd be a lot worse. [10:46] I don't think that would work out if plasma started depending on the latest version of KF5 [10:46] plus, I think KF5 is alot more important now, since potentially other DE's like Razor Qt can potentially use them [10:47] and *they* might require the latest KF5 [10:47] and this is not even taking into account the many other KDE applications out there [10:49] ScottK: libplasma along with all plasma qml foo is (or was) supposed to be a framework, so getting patch releases for the workspace but not the framework will likely not give sensible resuilts. Even if version wise it would be possible, I don't think the quality will necessarily be reasonable. [10:50] shadeslayer: Did you talk about workspace cadence at all? [10:50] no [10:50] I think Riddell is probably more well informed in that area [10:51] who? what? [10:53] Riddell: workspace release cadence [10:55] what's the upstream plan? [10:55] Riddell: that's what I'm asking you :P [10:55] every 6 months I think is what the release manager (me) plans [10:56] what's changed from the KDE 4 world? [10:57] d_ed says 3 months here [10:57] so very confusing :P [10:57] Riddell: KF5 is releasing monthly initially [10:58] and then they'll work out if that is a suitable/deliverable release cycle [10:58] presumably we'll put it into the updates or backports PPA as appropriate === apachelogger changed the topic of #kubuntu-devel to: Kubuntu - So Utopic. | https://trello.com/kubuntu | http://qa.kubuntu.co.uk/ | Polo Shirts are available again!! https://holvi.com/shop/Kubuntu/ (Womens also) | Kubuntu 14.10/16.04 planning http://doodle.com/z5723iwv9cmc75y2#table [11:19] Riddell: Can you take a look at calligra precise in https://launchpad.net/~scarlett-7 it builds all parts fine in my chroot but continues to fail in the ppa. [11:21] Riddell: I'm back from holiday (4 weeks earlier then expected). Seems the old LO KDE4 maintainer came back :-) And actually he fixed two additional Qt4 bugs for LO :-( [11:22] jmux: hello, welcome home [11:22] jmux: I couldn't recreate the original crash so we had to postpone the stable releaes update anyway [11:22] Riddell: I'm currently testing LO master with all Qt4 patches. Not sure if he plans to upstream the stuff, as this is currently just attached to the QT bugs and not in their gerrot. [11:22] sgclark: looking at the configure part of the build log it's saying there's no kdeclarative and no KActivities that it can find [11:23] sgclark: I'll try to take a closer look when I get a chance [11:23] sgclark: in the mean time you could look at what's holding back baloo in precise in 4.13 backports http://qa.kubuntu.co.uk/ninjas-status/build_status_4.13.0_precise.html [11:24] Riddell: yeah I have tried several declarative(s). Ok I will look into that [11:24] Riddell: Yup - saw the mail. LO is currently a mess for us (4.1.x). That's why I'm back already, to help fixing LO bugs, and we're already postponing our release because of it... [11:25] erk :( [11:29] 'Morning folks [11:38] morning [11:39] Riddell: of course the minute I ask for help, I thinkk I figured out my problem with calligra. [11:41] oh? [11:46] kdelibs5-experimental-dev has the cmake files it is looking for. [12:04] If plasma or apps need newer KF5 then we don't update. Lack of upstream support means we need to be more conservative, not less. [12:09] That is assuming we bend the way the ubuntu wind blows. What if we were to bend the kde way? [12:09] I don't have a smartphone and some user is complaining that kubuntu/kde doesn't work with them. Is this true? [12:10] BluesKaj: what that matter to you then? ^^ [12:10] *would [12:10] and what does this have to do with unicorns? [12:11] Probably a good reason to use Debian. [12:11] ok nm , ill ask somewhere else [12:12] Having a stable release is essential to me. [12:12] imho, everything but ubuntu means a lot of additional trouble [12:12] monthly releasery done right has no impact on stability [12:13] KDE seems to be giving up on it since features are more fun. [12:13] that's not what they said [12:13] Eventually you have to stop updating and have a release. [12:14] in fact what the mail seems to suggest is proposing a more conservative feature inclusion than what is there right now [12:14] does anyone of you use kde telepathy on a regular basis? [12:14] If one wants to release monthly then master must be in a release quality state. Always. 24/7. [12:15] kdeuser56: same question: what does this have to do with unicorns? [12:15] Believe it when I see it. [12:16] apachelogger: I am not talking about unicorn in any way, that was a completely different question, sorry if it interfered with your conversation [12:16] For frameworks that can very much work, for workspace I find it questionable. [12:16] No feature branches means keep stuff local until you push to master. [12:17] In particular for frameworks this would probably have adverse effects anyway, as greater restrictions on what quality a feature must have before inclusion into master will in fact have the available developer time spread out more as they need to keep track of more stuff in different places [12:17] Seems like a recipe for breakage. [12:17] I don't think that is the plan to be honest [12:17] might as well use mail based version control then ^^ [12:18] The mail said no feature branches. [12:19] ScottK: " [12:19] * Features in released modules can only be introduced in a very fine grained [12:19] way so as to not jeopardize the stability; [12:19] " [12:20] the mail actually is contradicting itself a bit as the lead point is " [12:20] * Everything is developed in master, so each release will contain a few new [12:20] features and bugfixes; [12:20] " [12:20] I reckon the intended point is that a) things only land in master once their quality is assured b) master is the primary development focus and everything that gets developed targets master [12:22] rolling release [12:22] we did have an option of doing that a while ago, we decided not to [12:22] Riddell: rolling foundations != rolling workspace [12:24] If I wanted a rolling release I'd run Debian Unstable [12:26] apachelogger: use the updates PPA then [12:27] Regardless, since from whenever we stop updating we get no support from upstream, we need to stop early enough to make sure what we have works. [12:27] Riddell: what is the point of having a kubuntu release if the release is potentially entirely outdated by the time it is released? [12:28] apachelogger: outdates from whos point of view? yours or my mum's? [12:29] only developers want a monthly release, and they know how to use PPAs [12:29] no [12:29] outdated from you mum might have a broken application [12:29] because kubuntu did not cherrypick the fix that was needed to have it not be broken [12:29] * ScottK thinks chasing version numbers is pointless in this paradigm. [12:30] Eventually you have to stop and release. [12:31] yes, which upstream does once a month [12:31] If there are essential fixes, IMO upstream should do a bug fix release for it. [12:31] " * We don't have many contributors;" [12:31] Yes. And we do every 6. [12:32] 1 month after our release we're out of date. [12:33] Unavoidable. [12:33] by the time we release we are 3 months out of date [12:33] Yep. [12:34] But if we stop updating apps too, it should be fine. [12:34] yes, but taking versions mix-matching out of the picture for now [12:35] what if there is a bug in a framework [12:35] how does that bug gets fixed? [12:35] Either it doesn't or wr cherry pick. [12:35] how do we become aware of the bug? [12:36] Since upstream isn't going to support their releases, I don't see what choice we have. [12:37] not releasing every 6 months is one choice [12:37] Someone files a bug. [12:37] but also taking cadence out of the picture, let's say we release with a 3 month old upstream release that has seen 3 new versions since then [12:37] Not if we're part of Ubuntu it's not. [12:37] how do we become aware of the bug considering we do not track upstream bugs [12:38] and if we disbanded the bug tracking policy we have where everything is supposed to go upstream, who is going to triage the bugs on launchpad and going to find the relevant upstream bug report and then the relevant upstream fix [12:39] Dunno. Maybe upstream gets tired of dupes from Kubuntu and tells us. [12:39] how is our product stable then? [12:41] Since upstream has given up stable support I don't an easy answer. [12:41] don't have ... [12:41] upstream has not given up stable support, a feature is not the opposite of stable [12:42] They've outsourced it to distros. [12:42] if I have a library foo and add a function play_feature_song() that function may be completely isolated from everything else [12:42] and if that function is isolated then nothing that is not using the function will be affected by it's addition [12:43] As long as no one screws up. [12:44] the way they intend to make sure that no one screws up is that there is 100% test coverage and CI [12:44] I'm skeptical. [12:45] test coverage and CI provides solid data, compared to what we worked with in the past which is of the kind "uh, no one reported a bug with 3000 duplicates, software must be fine for release" [12:45] of course there is still the possibility for regression etc., but that risk is there always [12:46] the tiniest of fixes could break something on the other end of the platform [12:46] Not changing won't cause regression. [12:46] it also won't fix anything [12:47] Yep. It's a balance. [12:47] which is where CI and autotests come in [12:47] you know that the outlined expected behavior of the tests is still met all the time [12:48] perhaps a test is inaccurate or not complete enough, so you may get a regression at one point, but until the regression happens you will not know that this is the case [12:49] it's the same with our SRUs, any of them can cause a regression but until the regression happens we will not know, and we can do nothing more but hope that the regression is noticed before the SRU gets moved to the release pocket [12:50] so the proposed no-feature-freeze scheme for frameworks might sounds like it would produce lower quality or less stable releases, but since a rolling release requires constant automated QA it will at the very least offer the same quality [12:53] actually let me give you a hands-on example based on packaging ... packages can have file conflicts, so you put up a file-move-freeze after which installation paths may not change anymore. between that freeze and a release you then try to find all possible conflicts and hope you did not miss any. instead of putting up that freeze you could just as well have continious automated checks for file conflicts and know at any given time that this [12:53] particular error case is not happening [12:54] if your only concern were file conflicts it will then enable you to release at any given point in time because you made sure that everything always works [12:55] Tough case though because it depends on upgrade order which isn't deterministic. [12:55] and that's essentially what upstream intends to do, and to me it seems that will work just fine... automated QA only gets problematic when the amount of things you need to assure exceeds the amount of assurance you can automate [12:55] a monthly cycle for the workspace seems unrealistic to me for example as gui tests are much more work and much harder to get right [12:56] I get the idea. I'm about 98 percent sure TB wouldn't approve an MRE. [12:57] Maybe FFe during development, but you still eventually have to stop. [12:58] Canonical upstream have all the CI stuff and they can only push bug fixes. [12:58] there's probably reasons beyond quality for that TBH [12:59] e.g. IIRC for various mobile ISO certifications of a product you must not deliver feature updates (at least not automated ones) [12:59] but yeah, that's the implementational issue [13:00] for now I'd be happy if we could all accept that what upstream does isn't necessarily worse than we are going with right now :P [13:01] I'm sure it's worse for us. [13:01] politically [13:01] The reply you got pretty well confirms it for me. [13:02] No. I don't think it'll work out nearly as well as they claim. [13:02] I need to go. [13:21] any progress enabeling dbgsym creation for ninjas? [13:39] Riddell: ok so the libboost that is holding up baloo... the precise version is 1.46 baloo and akonadi depend want 1.48 which does not seem to exist in kubuntu, have 1.49 1.53 1.54... every version but. [13:41] 1.48 is in precise/universe [13:43] yofel: ok, how do I get the staging package to see that? [13:43] our precise backport hook uses 1.48 so I guess that's the right one [13:43] let me look at the log [13:43] so update baloo to use 1.48 I would guess [13:44] baloo is asking for 1.48 and erroring that it does not exist, 1.6 will be installed instead [13:44] 1.46 rather [13:45] that's not what the error says [13:45] it tries to install 1.48, but 1.46 is to be installed as well and as they both conflict things fail [13:46] nowhere does it say that 1.48 doesn't exist [13:46] ok sorry [13:46] np, apt resolver errors tend to be hard to read :( [13:48] hm, I need to testbuild this to debug it [13:52] * yofel just retried baloo [13:52] this works fine locally, so maybe it's a PPA config issue [13:52] ok [13:53] *sigh* [13:53] let me also retry all the builds broken by lp [14:00] apachelogger: anything that you want me to do? [14:00] build me a time machine plz [14:00] shadeslayer: nothing in particular, you could look at trello [14:01] there's 3 billion cards already [14:01] apachelogger: 5 minutes from now, you shall have a time machine, if you do not, then that means I have tried my entire life to build you a time machine but the physics just doesn't work out [14:01] voila delegated all responsibility to future me [14:01] * apachelogger raises a lazy! sign [14:02] dude, in some timeline I'm building you a time machine [14:02] my eyes hurt from looking at bash [14:02] shadeslayer: line, lol [14:02] ye know nothing about the timez [14:03] homework assignment for today: watch moar doctor who [14:03] I have to go apartment hunt [14:03] that's my homework for this week [14:03] well that doesn't sound fun [14:03] it's not >.> [14:03] I just moved a month ago and I have to move yet again [14:04] that's quite shitty [14:04] shadeslayer: you should get a loft [14:04] it's very shitty [14:04] apachelogger: the problem with that is that pretty much all apartments here are rented out by agencies, and they charge you like a 1000 EUR as agency fees [14:04] it's a rip off I tell you [14:05] :O [14:05] apachelogger: https://trello.com/c/YNgHRmvZ < I'm just going to add it, since it's a KSNI [14:05] and it'll autohide on systems without touchpads [14:05] I still don't see why one cannot device plasma api for that [14:05] device he wrote [14:05] xD [14:05] apachelogger: because the plasma is in freeze [14:06] shadeslayer: yeah, except for master [14:06] or I think it is in a freezuroo [14:06] oh [14:06] the problem is [14:06] I guess one could write a hasTouchpad property [14:06] like hasBattery [14:06] shadeslayer: yeah [14:06] or [14:06] someone maybe feels like actually writing sane api that lets you do simple hardware queries in a scalable manner :P [14:07] but hastuchpudding also works I guess [14:07] k putting on my todo [14:08] you put delegating on a todo [14:08] my aren't we fancy :P [14:08] I'm delegating future self to do this :P [14:11] * apachelogger throws a future empty bottle of codeine [14:19] apachelogger: just read the kf5 release discussion, and I personally agree with Scott on most points. [14:19] As long as we stay being an ubuntu flavor, updating kf5 the way upstream wants it is impossible. Nor do I trust upstream to not break stuff - and saying everything will be auto-tested etc. is nice, but I've seen to many occations where upstream devs simply ignored test results [14:19] for 14.10 we can keep it in a PPA and monitor what happens [14:19] yofel: FWIW the email says that all test breakages are show stoppers [14:19] so they can't release with tests failing [14:20] if they do, they've failed in their promise [14:20] shadeslayer: if I see like 3 actual releases where they really do handle it like that I might consider that they really care about that [14:20] currently I don't trust them [14:21] yofel: right, but in order to have such releases, we must give upstream the opportunity to actually change their release workflow and then see what happens [14:21] if they can deliver quality releases in 1 month time spans, I don't see why we can't get a policy exception [14:22] sure, as long as they understand that we can't possibly ship that in the official release as it's unmaintainable for *US* [14:22] because as far as I can tell, that's the only blocker, policy [14:22] right, and policy requires 0 regressions. For usability, content, API and ABI [14:22] and I don't want to change that [14:23] that's nearly impossible, even on current bug fix releases, [14:24] unless we don't change anything [14:24] at which point the KDE SC MRE becomes moot [14:24] and we shouldn't be updating KDE SC right now [14:26] sure, and in the end we're compromising there. If upstream can really verify that there will be no ABI changes and no major changes to UI components and features get properly tested then we might get away with updating it [14:26] but only then [14:27] mentioned before, but afaik Frameworks is API/ABI frozen starting beta or sth [14:28] can KF5 really cover every single feature with unit tests? that's not possible for projects with lots of dedicated developers never mind a largely volunteer project [14:28] as is the KDE SC mostly, and we're still increasing X-Debian-ABI in some places. For Frameworks X-Debian-ABI is a no-go [14:28] KDE SC has no binary compatibility promise except kdelibs [14:29] (but they ought to bump the soversions which they do break ABI which isn't always done) [14:29] yofel: just confirmed, ABI/API is frozen for the entire 5.x cycle [14:29] so new stuff will be added, but previous stuff won't be broken [14:30] I also proposed a automated ABI checking tool actually [14:30] ok, we'll see how much they care about that [14:30] not sure if that was mentioned in the email [14:30] can't remember, but that would really be nice [14:31] btw can I push for a "Kopete suggests imagemagick" in 14.04 ? [14:32] yofel: "Nor do I trust upstream to not break stuff " it's their software, I guess they have every right to break it as much or little as they feel comfortable with? [14:33] apachelogger: sure, but if I use a distribution, then I expect that a bugfix updates (i.e. everything in -updates) will not cause any major breakage in my application [14:33] and it's OUR responsibility to guarantee that [14:34] if upstream goes and breaks their applications that they sure can do that, as we can decide to then not ship that [14:34] actually, I think it's our resposibility to make sure fixes get across as proposed by upstream [14:34] then we probably should remove kde branding [14:34] but not our responsibility if those fixes cause breakage [14:34] assuming we haven't meddled with said fixes [14:35] I agree, as long as we're talking about bugfixes. [14:35] saying that we are more responsible than the actual developers of the software leads down a very dangerous road [14:35] ^^ === jono is now known as Guest72975 [14:37] well true, but it's our responibility to verify that said developers don't do something crazy. [14:39] no it is not [14:40] we are not the quality police, in particular when we do not even work on it [14:41] a lot of what distros do is review upstream for, if not quality, at least sanity [14:41] our responsibility is fiddling upstream's work into a package system and ensure platform cohesion [14:41] and looking at the track record of that I'll argue that upstream probably has as much right not to trust us to screw up as we have to not trust upstream to screw up [14:41] ^^ [14:41] ok, can we please get rid of our long install files and delete all symbol files? Those are sanity QA checks after all [14:41] seeing as people are involved there's screwup everywhere [14:41] what matter is how one deals with it [14:42] if upstream doesn't fix any bugs, you may choose to kick their software off the seed or even the archive, or well, fork it making us the upstream at which point we are responsible [14:43] yofel: because I could not land a patch that retracts a library interface? [14:44] apachelogger: because you said we're not responsible for upstream QA, so why should we bother? [14:44] yofel: we are not QAing upstream [14:44] if we were QAing upstream we'd be doing that stuff on the unaltered release tarballs [14:45] but we don't because that's ultimately a safe guard against us screwing ourselves over [14:45]