Re: KDE/4.11 branched what to do with kde-workspace?
On Monday 15 July 2013 14:42:14 Sebastian Kügler wrote: - It will likely be impossible to merge frameworks into master later This is complete FUD. If you regularly merge bugfixes from master to frameworks (surely you want to do that, right?), then merging frameworks to master is completely trivial. Proof: -asterix- dfaure 8:43 /d/kde/src/5/kf5-bis (master) git merge origin/frameworks Updating 221fe25..8b30c2d Fast-forward [...huge list of files gets printed here...] Done. If, on the other hand, you don't merge bugfixes from master to frameworks, then you risk losing bugfixes, and we can still do one big merge with the right option to resolve any conflict by taking the code from frameworks. - merging master into KF5 is not a 10 second job, it wasn't a walk in the park last time I did it (granted, that's hopefully alleviated with the freeze) Yes that's where the hard work is, and yes you can minimize the issue by not making many changes to the stable branch. But you have to do such merges anyway, whatever you call the branches. (In the alternative setup you mentionned, it would mean merging 4.11 into master -- different names, exactly the same work). An alternative in all this (mentionned by Sebas yesterday during the bus trip) would be to have master == stable, i.e. 4.11/4.12, and frameworks branches. It would still create a small surprise where's the 4.11 branch?, but it wouldn't drastically change the meaning of master (especially when there seems to be consensus on master should be stable (i.e. useable for daily work)). I think this is less optimal, but I'm willing to accept it as a compromise. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5
Re: KDE/4.11 branched what to do with kde-workspace?
On Thursday 18 July 2013, Sebastian Kügler wrote: Hey, On Tuesday, July 16, 2013 22:03:51 Alexander Neundorf wrote: On Tuesday 16 July 2013, Martin Graesslin wrote: On Monday 15 July 2013 14:42:14 Sebastian Kügler wrote: On Tuesday, July 09, 2013 18:57:41 Albert Astals Cid wrote: So the kde-workspace dudes decided they don't want a 4.12 release and that they'll do a LTS 4.11, fine, how do we fix that branch wise? After carefully reading everybody's opinion, I would like to make kde- workspace master our KF5/Qt5 branch, for the following reasons: +1, could we please get this going. The whole thread turned into quite some bikeshedding which is disappointing. I think there is a very good suggestion with the CMake option to fail the build. I must have missed that. Just the obvious that the cmake run of plasma needs to require a high enough version number of KF5 ? We require at least Qt 5.2, that should be satisfying this requirement, no? (Anything Plasma can't reasonably build against Qt4, since we've moved to QtQuick 2, and that is far from source compatible. (It's also the reason why we need to start on this sooner rather than later, Plasma, compared to other frameworks, requires more porting work. If the Qt 5.2 requirement is not enough, tell me what to do, and I'll do it. KF5 is not versioned, but no worries, Yes, that came to my mind the last days too. I guess it should be, shouldn't it ? I mean, currently everything is already 5.0.0. Should we set this back to 4.99.0, SOVERSION 5, or so ? kde-workspace won't even build on top of last weeks kdelibs[frameworks]. This is something that requires a bit of adjustment, maybe reintroduce BIC/SIC Mondays again at some point? I guess this will be more interesting than before once everything has been split into separate repositories... Alex
Re: KDE/4.11 branched what to do with kde-workspace?
On Monday 15 July 2013 12:27:53 Aaron J. Seigo wrote: So please excuse me if I don’t base my thoughts on your input on how to maintain a module. WTF? This is a very very low blow. I recognize that the *initial* solution for kdelibs was broken and a bad idea. This is why we're not doing that anymore! What I'm recommending is the *current* kdelibs solution, which is working pretty well: * 4.1x stable branch (currently 4.11) * master branch (with very very little difference to 4.1x, so merging is really trivial) * frameworks branch. *Minimize disruption* For whom? For all the developers and users who compile KDE from sources, for packagers, etc. Not for our users (a well maintained 4.11 Plasma Desktop is far less disruptive). You're twisting my words. What, in my suggestion, leads to a not-well- maintained 4.11 plasma desktop? ?? The disruption you mean is for those who build from source, from git master without tracking what’s going on. If every module switches master to Qt5 at a different random point in time, tracking what's going on is going to be a real pain! Unlike kdelibs, kde-workspace master won’t build against 4.x. Sure. Let's break things for everyone, it's the best solution, clearly. (irony) Unlike kdelibs, which pretty much everyone relies on for their applications, nobody relies on kde-workspace to build their apps. This is no excuse for breakage. Unlike kdelibs where a minority (unfortunately) went to work on Frameworks 5, it is the entire workspace team in coordination and agreement that are going to do this work so we won’t be fighting against co-contributors about what should be in a given branch. So, you just ignore the needs of anyone NOT part of the workspace team? Great way to work within a community. Ergo, the disruption is likely to be small, and we’ll do our best to keep it that way. I strongly believe this to be wrong. Every day people will be asking what the heck happened with kde-workspace master, it doesn't compile with all the other modules from master. Consistency is a great way to avoid bad surprises. We want to do a long term release of 4.11. Something that doesn’t have new features or new i18n, but which just gets boring old bug fixes and translations. That was my initial plan for kdelibs too, and we had proof that it failed - simple bugfixes sometimes require new i18n. You say that you don't want to follow my suggestions - at least learn from my mistakes! Doing a 4.12 / 4.13 makes that infeasible: it would mean continuing to track the 4.11 branch *and* master *and* the Qt5 branch *and* the eventual 4.12/4.13 branches. That is a recipe for disastrous neglect. This is exageration. Once you maintain 4.12 you can forget about 4.11. This is the way it has always been. So it's really just stable+master+workspace, and for the Nth time: merging from stable to master is trivial, when almost- nothing happens in master. Please, let us focus on 4.11 and Qt5. We can manage that. You're making the same mistake as I did with kdelibs. I resent people telling us we can do more than we know we can. I can do the merges from stable to master, if it solves this issue. * merging from 4.11 to master is really not a problem. In fact if you don't do anything else in master, it will really be trivial. None of us is concerned about merging branches with git. We do it pretty often as part of our usual development workflow. Since we know merging 4.11 into master is trivial if we don’t change master much, then that can’t be the problem we’re worried about, can it? We haven’t mentioned this as a cause for concern becauseit isn’t one! And yet it's the only difference between stable+frameworks and stable+master+frameworks. I can’t support custom tools or people’s heads, obviously, other than to communicate. Wrong. You can also do what people expect. master branches working together in all modules, rather than starting to create exceptions, which will become a big mess quickly. How will we know which modules should be taken from master and which modules should be taken from 4.11, to get the future-4.12 KDE SC, once some more modules have started to follow the kde-workspace master-is-qt5 solution (and possibly even some modules following a different convention, e.g. to match kdelibs) !!! A big mess is coming our way. But you don't see that, you only look at kde-workspace... For tools that use projects.kde.org, however, perhaps we can define the “current default branch” there? Not everyone uses tools that use projects.kde.org. We’re trying to avoid having to merge a wildly diverged branch back into master 7-12 months time when bug fixes and translation changes have also been landing in that same branch. You'll be merging master to frameworks regularly anyway. So they won't diverge, all the changes from master will be in frameworks. At which point merging frameworks back to master will be trivial.
Re: KDE/4.11 branched what to do with kde-workspace?
Hi all, Just a side note here: using any branch name other than 'frameworks' for KF5 based development in kde-workspace will throw a wrench in the tools which depend on the KDE dependency metadata file. This includes the CI system and kdesrc-build as well to a certain extent. Fixing this will require negation statements in the dependency metadata file to strip kde-workspace of it's branch autosensing dependencies and replace them with branch strict dependencies. Dependencies which do not yet support Qt 5, or support Qt 5 with the same branch cannot be supported using this method - as kdelibs master will get dragged in. If kdelibs master gets dragged in, then the build will fail (as kdelibs master does not exist for Qt 5). ie. You will not be able to depend on those projects which support both Qt 5 and Qt 4 builds in the same branch, and which depend on kdelibs. You will also be imposing a maintenance cost on the dependencies metadata file. Regards, Ben Note: the statements would look something like this: kde/kde-workspace[master]: -kde/kdelibs kde/kde-workspace[master]: kde/kdelibs[frameworks] kde/kde-workspace[master]: -kde/kdepimlibs kde/kde-workspace[master]: kde/kdepimlibs[frameworks] kde/kde-workspace[master]: -kde/kdelibs/kactivities kde/kde-workspace[master]: kde/kdelibs/kactivities[frameworks] kde/kde-workspace[master]: -kde/kdelibs/nepomuk-core kde/kde-workspace[master]: kde/kdelibs/nepomuk-core[frameworks]
Re: KDE/4.11 branched what to do with kde-workspace?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David Faure wrote: *Minimize disruption* For whom? For all the developers and users who compile KDE from sources, for packagers, etc. I can say +1 to that. Stuff like Project Neon or some things we're trying to do in openSUSE to *ease* the need for those doing development / bug reporting, avoiding a full source build, would grind to a halt with master = frameworks. - -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBCAAGBQJR5owNAAoJEAE/pQtuGk55O2IQAImWR7vOna8HXi+DH7WXwEiH DOpGRGRDU2vNvPCC1UhtAfSAptlztsMWvpmXtAKemaWnSC+IzdO+4Je0iN3Dnmt6 jGFAf0q/NwJtA7jYQaycZs5CUTBrBxwx9SjAdOf51LglqznXdQCk/tsZGfCmFg5E VF4FVVM1OxmkF8jc0desCmrKp30GVyc6ROzFpNQ3T7JDrPYsrXeVGS4YXXk/GgCq RczmZMnp70wYULYcx5XZRGhCIb6lhWNV7eFJC8eMABm1hUgfhUD8GgwyKd1Ks4Te KEj4N2fWIK21VNAT7cQEExXE9mnESZY6pyPV8XHAyvpr2TtpnvTxhQgiJ55eaqH9 gD9Saqa2dgBlyZ4vw6LAagSFLBvfsMvJqk2tMAik74MZqe2rK5FYkh0OkfyKS37T LlA8wH9IXN2/Qa/MYOBWgXno5eWm4jE8WrAp6lw7zkREMXYSsxcJm6LbOTi73xYm HOY/lAtKX2hrYRLdEYlGcNE0TBnORKwOcf+/TGRXk4FZ5m3Iafm2ZzMW5m2iDYz/ dMHaRHrx0DZXiLSBliyQEexMWtqUKrmyunsaKL1yuNz4FI2wPOO7k++o9OCMLvod 9rHDAOhovX66VXn9Dw4i3cJfNIyctu01cOQ8f6v4Sq96CZzw+MNu2dPL/nEBQ318 +8AE/33HpV4NWJwTn/8F =a8GG -END PGP SIGNATURE-
Re: KDE/4.11 branched what to do with kde-workspace?
On Monday 15 July 2013 14:42:14 Sebastian Kügler wrote: Hey, On Tuesday, July 09, 2013 18:57:41 Albert Astals Cid wrote: So the kde-workspace dudes decided they don't want a 4.12 release and that they'll do a LTS 4.11, fine, how do we fix that branch wise? After carefully reading everybody's opinion, I would like to make kde- workspace master our KF5/Qt5 branch, for the following reasons: +1, could we please get this going. The whole thread turned into quite some bikeshedding which is disappointing. I think there is a very good suggestion with the CMake option to fail the build. So sebas could you please add one and just go ahead? Cheers Martin
Re: KDE/4.11 branched what to do with kde-workspace?
On Friday, July 12, 2013 17:48:50 David Jarvie wrote: On Fri, July 12, 2013 4:42 pm, Aaron J. Seigo wrote: * there were 2 main reasons the branched-kdelibs shifted back to master- kdelibis: * people were too stubborn and too (willfully) uninformed to understand why this was a useful thing and just kept pelting it with stop energy at every possible opportunity. That's unnecessarily negative - why do you think that people would willfully remain uninformed? I don’t known the why, I just saw the discussions and they were too often characterized by stubborness and a lack of informed opinion. Much more likely is that they would be innocently uninformed due to not having seen announcements. Even for After having been pointed personally to the relevant materials, that’s no longer an excuse :) I’m certainly not suggesting everyone was this way. It was certainly a minority; but there were enough who were, and enough people who accommodated their stop energy. My point was not that *everyone* is stubborn or willfully uninformed, but that the flip flopping of strategies for kdelibs branches had a lot to do with those who were combined with the development requiring an extended period of time. It had very little (if anything) to do with the technical merits of the plan. So looking at it as somehow being a relevant reflection of that doesn’t make much sense. best of intentions) for old habits to take over and to accidentally use master again. This happened to me more than once. So how can we make that clearer for people and hard for this sort of mistake to be made? Here’s a possible idea: we could make the build fail (along with a relevant message on console) unless a specific env var or a cmake option is passed. If it doesn’t build, you probably won’t end up using it, and hopefullya build failure gets noticed. Example given: Build-tool failed to follow the repository switch of amarok (it was announced. i missed it because of being very busy) and continued to build the old stuff for months without problems. I agree. I'm sure that this must have caught out innocent people more often than willful miscreants. Which is why we have projects.kde.org with the projects xml file which allows tools to track these movements. When we identify situations where we get caught out, we can look for ways to minimize the chances for that happening in future. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: KDE/4.11 branched what to do with kde-workspace?
Hey, On Tuesday, July 09, 2013 18:57:41 Albert Astals Cid wrote: So the kde-workspace dudes decided they don't want a 4.12 release and that they'll do a LTS 4.11, fine, how do we fix that branch wise? After carefully reading everybody's opinion, I would like to make kde- workspace master our KF5/Qt5 branch, for the following reasons: - It will likely be impossible to merge frameworks into master later - We do not have anybody willing to maintain kde-workspace[master] - kde-workspace master and plasma-frameworks master would then be both on KF5/Qt5 - merging master into KF5 is not a 10 second job, it wasn't a walk in the park last time I did it (granted, that's hopefully alleviated with the freeze) - It won't be possible to build k-w[master] against 4.x, so it's not a silent unexpected behavior - The whole team feeling responsible for this code has decided to move on, what more do we need, really? In my opinion it's wrong to try to optimize our development process for people who use git-based builds. We do releases for that (and using git won't have a lot of benefits in terms of new features or lots of fixes, since we release regularly, and nothing will pile up this way. I'm committed to working on this code a lot, so I'm one of the stakeholders. Also, the messy kdelibs branch naming strategy doesn't scale. We'll run into this exact same discussion again and again as we start porting over more modules. Plasma is just early here, but not an exception in any way. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: KDE/4.11 branched what to do with kde-workspace?
On Mon, July 15, 2013 12:27:53 Aaron J. Seigo wrote: On Saturday, July 13, 2013 23:36:24 David Faure wrote: * let master be the branch that will become 4.12, even if you (= the workspace developers) don't intend to do more than bugfixing on 4.x, there will always be a need to separate fixes that can go into the next bugfix release and fixes that need a new i18n, or smallish features contributed externally. We want to do a long term release of 4.11. Something that doesn’t have new features or new i18n, but which just gets boring old bug fixes and translations. Doing a 4.12 / 4.13 makes that infeasible: it would mean continuing to track the 4.11 branch *and* master *and* the Qt5 branch *and* the eventual 4.12/4.13 branches. That is a recipe for disastrous neglect. So it sounds like the issue in this case is that kde-workspace's KDE 4 bugfixing will be concentrated in the 4.11 branch lineage? While that is fine, I don't see how that is different in practice from doing 4.12/13 development in a bugfix-only state, except for the version numbers. Perhaps this is more semantically clear though (the reason it's still called 4.11.y is that there are still no new features)? Please, let us focus on 4.11 and Qt5. We can manage that. I resent people telling us we can do more than we know we can. I resent people interpreting a given comment in the most-negative possible light. :) Unless *I'm* the one misinterpreting things it appears you both are suggesting to maintain 1 KDE 4 branch at a time and do development in Qt5/KF5, and that the only point of disagreement here is what to call the KDE 4 development. The *actual* point of disagreement is later in your email. It’s the merge from our Qt5 devel back into master and the branch management between 4.11, master and frameworks. If you want us to learn from the kdelibs experience, there it is! It seems this is the point of concern then, no? By branching off the eventual Plasma Workspace 2 from KDE/4.11 we can 'gracefully' change over to Qt5/KF5, and since that development will happen in master there will be no icky problem merges *back* to master when it comes time to do a cut-over. Is that the idea? An alternative would be to still do development in 'frameworks' but have frequent curated merges back to master (keeping with the idea of always- summer), but you would still need to reserve master for the use of development and so it would still not be suitable for LTS KDE/4.x. I don't see the latter as being useful now (assuming we are pushing frameworks development into master) since those worried about Qt5/KF5 will be having to track the bleeding-edge anyways. But it might be useful when we get closer to thinking about preview and alpha releases for more people to be able to start banging on Qt5/KF5 without it breaking every other day. version, but still usable. That's what everyone building KDE from sources expects, including all current scripts (kdesrc-build, build-tool, jenkins, custom tools, people's heads, etc. etc.). Don’t I can’t support custom tools or people’s heads, obviously, other than to communicate. For tools that use projects.kde.org, however, perhaps we can define the “current default branch” there? That should be possible in the XML. A variant of that idea is already used for i18n, and kdesrc-build supports that already via the use-stable-kde option (which repeats the scheme kdesrc-build used during the KDE 3-4 transition). The definition is of the current *stable* branch though, if we want *default* branch to mean something different then we might need to add that to the XML metadata so the tools can use it where appropriate. I will support whatever. Would it perhaps be useful to have in kdesrc-build a 'news to the users' feature that developers could tie into? Most of the time when we made a breaking change on the KDE side I try to fix it up for the users within kdesrc-build, but I don't see a way to assume that a user building kde- workspace master isn't actually doing it on purpose. Even if I check the kdelibs version they build, they could be using a self-built KF5. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
Re: KDE/4.11 branched what to do with kde-workspace?
On Mon, July 15, 2013 10:46:49 Aaron J. Seigo wrote: On Friday, July 12, 2013 17:48:50 David Jarvie wrote: best of intentions) for old habits to take over and to accidentally use master again. This happened to me more than once. So how can we make that clearer for people and hard for this sort of mistake to be made? Here’s a possible idea: we could make the build fail (along with a relevant message on console) unless a specific env var or a cmake option is passed. If it doesn’t build, you probably won’t end up using it, and hopefullya build failure gets noticed. That (or something like it) would be wonderful. Even where the tool *wants* to support Doing the Right Thing I have taken a dim view at rewriting config files for the users. However I can have the build failure cause kdesrc-build to display a specific warning to the users that they have to adjust their config, if you want to coordinate something like that I'd be happy to put it in. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
Re: KDE/4.11 branched what to do with kde-workspace?
On Freitag, 12. Juli 2013 17:47:53 CEST, Aaron J. Seigo wrote: On Wednesday, July 10, 2013 22:39:29 Thomas Lübking wrote: There'll have to be (minor) patches to kde-workspace (you cannot keep shipping known and fixable crashes), thus new tarballs and shipping kdelibs 4.13.2, workspace 4.11.12 (depending on kdelibs 4.13.2) and kde-runtime 4.13.2 does not sound very reasonable to me. regardless of what happens in 4.x for x = 12 ... .. what do you think is going to happen wiith Plasma Workspaces 2? That is completely unrelated. The point was not there's no scheme at all but unilaterally deviating from the scheme is confusing. A break for KF5 or PW2 as it was for Xorg, that completely abandons former versioning is no problem. But KDE has ever released as block and so far still releases as block. If now ppl. get mostly block and some bits of old block that is far more confusing to them than always combining linux 2.4 and XR11v6 - or after a clear split (now) be fine about xorg stuff ranging from 1.04 to 1.14.2 You can expect wrong use of version tags, failing scripts and just poor users sitting in front of packages.ubuntu.com, searching for the proper package. - Also there will very likely be bugfixes suitable for some 4.11.x and bugfixes only suitable for a 4.12.0/4.13.0 release. That means you will either a) threaten users with patches in minor releases that would normally have gone into major ones b) expect patch submitters to hold back their patch until 4.11 will no more tag 4.11.6 but the next one will be 4.12 c) introduce a tic-toc release for kde-workspace (advising conservatve distros to skip the odd ones, so risky patches are more tested for the even ones) d) draw something else out of your magic hat. As the major conflictive concerns seem that a) a PW2 branch cannot be re-merged into master b) ppl. will stumble about master being something else i suggest to branch off PW2 AND 4.xx from current master. Then freeze master in a way that makes it unusable for everyone. No pushing, and ideally no (re-)checkout either. On checkout, commit, clone or update attempts either get developers/distros/users a message, or (in case that's absolutely not possible) have at least a synthetic commit --- kde-workspace is ABSOLUTELY FROZEN for the change to PW2 There're no updates and you cannot push local commits upstream. Please use PW2 to commit to future plasma-workspaces 2 or 4.xx to commit bugfixes for near major releases of old kde-workspace. -- This way you'll maintain a clean master - PW2 history, no merge problem. otoh you prevent any confusion about the nature of master *by git rules* and not some blog entry or whatever big time annoucenments you might have in mind, which frankly, and i'm sure you're absolutely aware of this, have reliably and more than once proven to completely fail in past incidents. Cheers, Thomas
Re: KDE/4.11 branched what to do with kde-workspace?
On Monday 15 Jul 2013 09:46:49 Aaron J. Seigo wrote: On Friday, July 12, 2013 17:48:50 David Jarvie wrote: best of intentions) for old habits to take over and to accidentally use master again. This happened to me more than once. So how can we make that clearer for people and hard for this sort of mistake to be made? Here’s a possible idea: we could make the build fail (along with a relevant message on console) unless a specific env var or a cmake option is passed. If it doesn’t build, you probably won’t end up using it, and hopefullya build failure gets noticed. I think that would answer my concerns. As long as there is clarity (e.g. through the build failing), it doesn't matter too much if a 'non-standard' branch is used instead of master. Best would be to display an explicit message when the build fails, saying that the KDE/4.11 (or whatever) branch is the correct one to use. -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: KDE/4.11 branched what to do with kde-workspace?
On Thursday 11 July 2013 11:55:54 Sebastian Kügler wrote: I'd be in favor of moving master to Qt5/Frameworks5 soonish: - I don't want to have to keep track of merging between 3 branches, 2 is really enough - kde-workspace developers have decided to move onto Frameworks5 after 4.11 is out, using master for this is natural This means that, just like with kdelibs, you should use the KDE/4.11 branch if you want to build the current version from git. This knowledge is outdated, we changed that in kdelibs to go back to something that created less surprises. I feel strongly about what kde-workspace should do in the current situation, actually, after having gone through multiple solutions with kdelibs: *Minimize disruption* This means: * develop qt5/frameworks stuff in a frameworks branch * let master be the branch that will become 4.12, even if you (= the workspace developers) don't intend to do more than bugfixing on 4.x, there will always be a need to separate fixes that can go into the next bugfix release and fixes that need a new i18n, or smallish features contributed externally. * merging from 4.11 to master is really not a problem. In fact if you don't do anything else in master, it will really be trivial. In comparison, the merge from master to frameworks is always going to be infinitely more fun, given all the changes you're going to do to the destination branch. Really: master is not where most developers work. master is: the latest version, but still usable. That's what everyone building KDE from sources expects, including all current scripts (kdesrc-build, build-tool, jenkins, custom tools, people's heads, etc. etc.). Don't create disruption for hundreds of people just to save typing a 10-seconds git merge KDE/4.11 every 2 weeks or so in master. Minimizing surprises also means doing exactly what kdelibs is now doing (forget about the initial plan, it failed). And that means: a stable branch, a master branch which is basically the same but gives room to new i18n and stuff, and a frameworks branch where most of the development happens. No changes to anyone's workflow, including translators, testers, powerusers, distros, kde-wide bugfixers, etc. The only ones who have to switch to another branch is the people switching to a qt5/frameworks based development, and these people have a lot more setup to do anyway, the git checkout frameworks is 1% of it all. Please, pretty please, minimize disruption. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5
Re: KDE/4.11 branched what to do with kde-workspace?
On Sat, July 13, 2013 23:36:24 David Faure wrote: No changes to anyone's workflow, including translators, testers, powerusers, distros, kde-wide bugfixers, etc. The only ones who have to switch to another branch is the people switching to a qt5/frameworks based development, and these people have a lot more setup to do anyway, the git checkout frameworks is 1% of it all. I can confirm that the time when kdelibs was blocked to a certain branch was more problematic for kdesrc-build users (and by extension, myself). In any event the branch 'master' should mean something semantically. At this point that means either 4.x or the Qt5/KF5 code that's coming up. It seems a bit early to declare that Qt5/KF5 will be the answer during the 4.12 timeframe, so that would tend to argue against making master target Qt5/KF5. Bugfixes and other minor fixes during the 4.12 (13, 14...) timeframe will still need to be committed somewhere (presumably somewhere else besides KDE/4.11) and 'master' would need to mean something during that time. So why not leave it the way it is now (master makes sense, 4.x bugfixes have a working dev branch), until we're ready to cut over Qt5/KF5 to be the new 'master'? Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
Re: KDE/4.11 branched what to do with kde-workspace?
On Friday, July 12, 2013 10:19:45 Andras Mantia wrote: On Thursday, July 11, 2013 07:41:37 AM Martin Gräßlin wrote: I agree that this is something we learned from kdelibs that we need to keep the releases going even if they do not contain new features. With kdelibs didn't we switch back to branch and tag it from master even though master is closed (which was not true due to some bugfixes)? It was let’s strive for accuracy: * master was never closed to bugfixes * there were 2 main reasons the branched-kdelibs shifted back to master- kdelibis: * people were too stubborn and too (willfully) uninformed to understand why this was a useful thing and just kept pelting it with stop energy at every possible opportunity. * it took so long to get frameworks 5 on track, that eventually the pressure simply won out those two point played into each other. this was a non-technical failure, so don’t look for technical justification from the kdelibs branch experience. if your point is that people will again be stubborn and ignorant and sabotage the effort, then we can discuss how to avoid that. *older*. Ask David Faure how many times he got complaints to merge the branch to master... had this actually been done according to the original plan, kdelibs would have remained at version 4.x (where x = 7?) and we would now be up to 4.7.some relatively big number and we’d never have merged into master. ever. this was a mistake. we can learn from that. we don’t need to repeat mistakes made when we try again. For this reason I suggest to keep master as now and branch from there every time and for a bigger refactoring use a branch (yes, this is the opposite I there’s a problem with that. in 6-12 months time, we’ll need to merge all of that back into master. or, i suppose, abandon master forever. if bug fixes continue on in master, it will be nightmare to do the merge as the PW2 code will have drifted signficantly in two ways: the code base is going to be reorganized (in a similar fashion to what is happening for frameworks 5 right now) and the changes in some components will be significant making changes in the stable branch (be it master or not) completely innaplicable to the newer work. thankfully, there’s an easier way to do this: * do all stable releases from a stable branch * make all bug fix changes in the stable branch * do all individual refactorings in branches * merge those branches down to master as they are ready * release from master in a year’s time and call it Plasma Workspaces 2 (or whatever) the challenge with this is means people who aren’t actually doing the work need to be supportive in some pretty small ways, namely: be ok with drawing releases from the 4.11 branch. that really can’t be too much to ask? -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: KDE/4.11 branched what to do with kde-workspace?
On Thursday, July 11, 2013 12:37:39 Frank Reininghaus wrote Merging frameworks into master in kdelibs has the following disadvantages from my point of view (besides the makes it harder for i agree; the window for doing this closed a while ago. we’ve made some poor decisions that we need to live with now, but we don’t need to make it even worse. so +1 for leaving kdelibs going in the trajectory it currently is. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: KDE/4.11 branched what to do with kde-workspace?
On Wednesday, July 10, 2013 22:39:29 Thomas Lübking wrote: There'll have to be (minor) patches to kde-workspace (you cannot keep shipping known and fixable crashes), thus new tarballs and shipping kdelibs 4.13.2, workspace 4.11.12 (depending on kdelibs 4.13.2) and kde-runtime 4.13.2 does not sound very reasonable to me. regardless of what happens in 4.x for x = 12 ... .. what do you think is going to happen wiith Plasma Workspaces 2? if anyone still thinks that there will be any guarantee that plasma workspaces will release with the exact same version #s and use the exact same release cycle as Frameworks 5, let me fix that for you: it won’t. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: KDE/4.11 branched what to do with kde-workspace?
On Wednesday, July 10, 2013 15:34:43 Michael Jansen wrote: Because of that it should be announced. BIG TIME. I am not hopeful because agreed. so what i’d like to see is a definitive listing of all the places that this should be announced and in what form. since i’ve gotten this wrong enough times in the past, i’d appreciate a listing of: * email lists to send an announcement to * blogs and forums that should get a posting * which web sites should be targeted for articles along with a suggested re-posting frequenc for each. i’ve tried numerous combinations in the past, and innevitably someone in this very community complains about not having heard about it. so if the people in the community can offer some direction, i’m happy to oblige and make sure all the suggested bases are covered. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: KDE/4.11 branched what to do with kde-workspace?
On Tuesday, July 9, 2013 23:45:39 Martin Graesslin wrote: If someone wants to do a 4.12 release from kde-workspace module it can be branched from the 4.11 branch. fwiw, i take no responsibility for branches other than the 4.11 one. if someone feels the burning urge to make a release 4.12, i’d stringly recommend that the relevant changes necessary be done in that branch. at most a tag to called 4.12 or whatever. but please don’t branch things unless you are signing up to take over maintenance (and will explain to people why there won’t be a long term 4.11 release) the workflow implications as well as the communication impacts have been considered in making this decision. calling the sixth (or whatever) stable release of the 4.11 branch “4.12.0” is misleading and dilutes the message of “we’re doing a long term series of releases based on this feature-frozen code base”. having a multitude of branches that the maintainers are not actually tracking is dangerous. people have been extremely receptive to the idea of a long series of point releases based on the 4.11 workspaces code. if packagers have real and demonstrable challenges with having kde-workspace 4.11.x installed with a kde-runtime 4.12, please let us know with clear explanations along with the expected impacts of those challenges. i have no interest in the “but that’s the way we’ve always done it” argument, but am open to real issues we may not be aware of at this point. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: KDE/4.11 branched what to do with kde-workspace?
On Friday, July 12, 2013 05:52:02 PM Aaron J. Seigo wrote: On Wednesday, July 10, 2013 15:34:43 Michael Jansen wrote: Because of that it should be announced. BIG TIME. I am not hopeful because agreed. so what i’d like to see is a definitive listing of all the places that this should be announced and in what form. since i’ve gotten this wrong enough times in the past, i’d appreciate a listing of: * email lists to send an announcement to * blogs and forums that should get a posting * which web sites should be targeted for articles along with a suggested re-posting frequenc for each. i’ve tried numerous combinations in the past, and innevitably someone in this very community complains about not having heard about it. so if the people in the community can offer some direction, i’m happy to oblige and make sure all the suggested bases are covered. I personally think there is no combination that will ever work. We have to many part time developers and people with limited resources. And all channels we currently use have to many content so its impossible to catch up after being away for some bigger time. Both Mailing lists and planet kde i mean. I guess we need a dedicated channel for these announcements. Either a smaller blog aggregator / dedicated blog or use a dedicated mailing list for that stuff. But i fear it will never be enough. There are to many people involved that don't know all processes we agree upon. I am quite sure the core devs will do it mostly right. That's why i would prefer convention over announcement. Don't break the expectations of your users. Don't go away from processes that people learned to take for granted unless there is a VERY good reason. Especially if nothing breaks for those thinking the old process is still valid. Example given: Build-tool failed to follow the repository switch of amarok (it was announced. i missed it because of being very busy) and continued to build the old stuff for months without problems. Mike -- Michael Jansen http://michael-jansen.biz
Re: KDE/4.11 branched what to do with kde-workspace?
On Fri, July 12, 2013 4:42 pm, Aaron J. Seigo wrote: * there were 2 main reasons the branched-kdelibs shifted back to master- kdelibis: * people were too stubborn and too (willfully) uninformed to understand why this was a useful thing and just kept pelting it with stop energy at every possible opportunity. That's unnecessarily negative - why do you think that people would willfully remain uninformed? Much more likely is that they would be innocently uninformed due to not having seen announcements. Even for people who saw the announcements, it's still all too easy (even with the best of intentions) for old habits to take over and to accidentally use master again. This happened to me more than once. On Fri, July 12, 2013 5:08 pm, Michael Jansen wrote: On Friday, July 12, 2013 05:52:02 PM Aaron J. Seigo wrote: On Wednesday, July 10, 2013 15:34:43 Michael Jansen wrote: Because of that it should be announced. BIG TIME. I am not hopeful because agreed. so what i'd like to see is a definitive listing of all the places that this should be announced and in what form. since i've gotten this wrong enough times in the past, i'd appreciate a listing of: * email lists to send an announcement to * blogs and forums that should get a posting * which web sites should be targeted for articles along with a suggested re-posting frequenc for each. i've tried numerous combinations in the past, and innevitably someone in this very community complains about not having heard about it. so if the people in the community can offer some direction, i'm happy to oblige and make sure all the suggested bases are covered. I personally think there is no combination that will ever work. We have to many part time developers and people with limited resources. And all channels we currently use have to many content so its impossible to catch up after being away for some bigger time. Both Mailing lists and planet kde i mean. I guess we need a dedicated channel for these announcements. Either a smaller blog aggregator / dedicated blog or use a dedicated mailing list for that stuff. But i fear it will never be enough. There are to many people involved that don't know all processes we agree upon. I am quite sure the core devs will do it mostly right. That's why i would prefer convention over announcement. Don't break the expectations of your users. Don't go away from processes that people learned to take for granted unless there is a VERY good reason. Especially if nothing breaks for those thinking the old process is still valid. Example given: Build-tool failed to follow the repository switch of amarok (it was announced. i missed it because of being very busy) and continued to build the old stuff for months without problems. I agree. I'm sure that this must have caught out innocent people more often than willful miscreants. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: KDE/4.11 branched what to do with kde-workspace?
On Wednesday, July 10, 2013 01:25:06 Andras Mantia wrote: On Tuesday, July 09, 2013 11:45:39 PM Martin Graesslin wrote: * master is opened for feature development and will lead to Plasma Workspaces 2 (or whatever the release will be called in the end). Does this mean that kde-workspace in master will exists, but with a different content (and I assume unstable)? Does it mean the KDE 4.11 branch of kde-workspace will be needed even for master users (or for KDE 4.11)? With different content, do you mean based on Qt5? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: KDE/4.11 branched what to do with kde-workspace?
Hi, On Tuesday, July 09, 2013 23:45:39 Martin Graesslin wrote: On Tuesday 09 July 2013 18:57:41 Albert Astals Cid wrote: So the kde-workspace dudes decided they don't want a 4.12 release and that they'll do a LTS 4.11, fine, how do we fix that branch wise? I don't see how that affects branching. * 4.11 is branched from master * master is opened for feature development and will lead to Plasma Workspaces 2 (or whatever the release will be called in the end). If someone wants to do a 4.12 release from kde-workspace module it can be branched from the 4.11 branch. I'd be in favor of moving master to Qt5/Frameworks5 soonish: - I don't want to have to keep track of merging between 3 branches, 2 is really enough - kde-workspace developers have decided to move onto Frameworks5 after 4.11 is out, using master for this is natural This means that, just like with kdelibs, you should use the KDE/4.11 branch if you want to build the current version from git. Likewise, it would probably make sense to merge frameworks into kdelibs master as well. That's a discussion that can be had here at Akademy. I can announce this change BIG TIME, so people know what we're up to. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: KDE/4.11 branched what to do with kde-workspace?
Hi, 2013/7/11 Sebastian Kügler: Hi, On Tuesday, July 09, 2013 23:45:39 Martin Graesslin wrote: On Tuesday 09 July 2013 18:57:41 Albert Astals Cid wrote: So the kde-workspace dudes decided they don't want a 4.12 release and that they'll do a LTS 4.11, fine, how do we fix that branch wise? I don't see how that affects branching. * 4.11 is branched from master * master is opened for feature development and will lead to Plasma Workspaces 2 (or whatever the release will be called in the end). If someone wants to do a 4.12 release from kde-workspace module it can be branched from the 4.11 branch. I'd be in favor of moving master to Qt5/Frameworks5 soonish: - I don't want to have to keep track of merging between 3 branches, 2 is really enough - kde-workspace developers have decided to move onto Frameworks5 after 4.11 is out, using master for this is natural This means that, just like with kdelibs, you should use the KDE/4.11 branch if you want to build the current version from git. Likewise, it would probably make sense to merge frameworks into kdelibs master as well. That's a discussion that can be had here at Akademy. Merging frameworks into master in kdelibs has the following disadvantages from my point of view (besides the makes it harder for people who are used to build the master branch of all KDE modules issue): 1. This makes it impossible to commit any non-trivial bug fixes (those that look like they should at least a bit of wide testing in betas/RCs before being pushed to users in a stable release) to kdelibs for KDE 4.x. 2. There will be some confusion concerning the KDE version, i.e., KDE_VERSION_STRING. If both 4.11.x and 4.12 beta releases (AFAIU, nobody has suggested to not release KDE SC 4.12 yet) are made from the same branch, what should the version in that branch be? Moreover, it is my understanding that the contents of kdelibs/frameworks are going to be split into lots of new repositories anyway. So why would we want to move the master branch of the soon-to-be-abandoned kdelibs repository to framworks/Qt 5 at all? Cheers, Frank
Re: KDE/4.11 branched what to do with kde-workspace?
On Wednesday 10 July 2013 01:25:06 Andras Mantia wrote: On Tuesday, July 09, 2013 11:45:39 PM Martin Graesslin wrote: * master is opened for feature development and will lead to Plasma Workspaces 2 (or whatever the release will be called in the end). Does this mean that kde-workspace in master will exists, but with a different content (and I assume unstable)? we have not yet talked about which branch we use. But just because we switch to Qt 5 doesn't mean it will become unstable ;-) Does it mean the KDE 4.11 branch of kde-workspace will be needed even for master users (or for KDE 4.11)? master is just a name one specifies in kdesrc-buildrc ;-) I don't think that this really matters to anyone except the developers of kde-workspace. And if we do important changes I'm sure e.g. Aaron will blog about it. Cheers Martin
Re: KDE/4.11 branched what to do with kde-workspace?
On Wed, July 10, 2013 1:19 pm, Martin Graesslin wrote: On Wednesday 10 July 2013 01:25:06 Andras Mantia wrote: On Tuesday, July 09, 2013 11:45:39 PM Martin Graesslin wrote: * master is opened for feature development and will lead to Plasma Workspaces 2 (or whatever the release will be called in the end). Does this mean that kde-workspace in master will exists, but with a different content (and I assume unstable)? we have not yet talked about which branch we use. But just because we switch to Qt 5 doesn't mean it will become unstable ;-) Does it mean the KDE 4.11 branch of kde-workspace will be needed even for master users (or for KDE 4.11)? master is just a name one specifies in kdesrc-buildrc ;-) I don't think that this really matters to anyone except the developers of kde-workspace. And if we do important changes I'm sure e.g. Aaron will blog about it. For those who don't use kdesrc-build, knowing which branch to use does matter. kdesrc-buildrc and blogging are fine, but there needs to be an simple way later on to know which branch to use, without having to search through config files which you don't have a copy of, or past blogs. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: KDE/4.11 branched what to do with kde-workspace?
On Wednesday, July 10, 2013 02:12:41 PM David Jarvie wrote: On Wed, July 10, 2013 1:19 pm, Martin Graesslin wrote: On Wednesday 10 July 2013 01:25:06 Andras Mantia wrote: On Tuesday, July 09, 2013 11:45:39 PM Martin Graesslin wrote: * master is opened for feature development and will lead to Plasma Workspaces 2 (or whatever the release will be called in the end). Does this mean that kde-workspace in master will exists, but with a different content (and I assume unstable)? we have not yet talked about which branch we use. But just because we switch to Qt 5 doesn't mean it will become unstable ;-) Does it mean the KDE 4.11 branch of kde-workspace will be needed even for master users (or for KDE 4.11)? master is just a name one specifies in kdesrc-buildrc ;-) I don't think that this really matters to anyone except the developers of kde-workspace. And if we do important changes I'm sure e.g. Aaron will blog about it. For those who don't use kdesrc-build, knowing which branch to use does matter. kdesrc-buildrc and blogging are fine, but there needs to be an simple way later on to know which branch to use, without having to search through config files which you don't have a copy of, or past blogs. And there are people using my tool (build-tool). There are people using their own script and some even doing it manually. There are the packagers who need to know. Not sure if there are distros that track our development versions. Linux from scratch or so? Because of that it should be announced. BIG TIME. I am not hopeful because this is the one area we fail to get consistent all the time. Announcing our version control strategy, changes and anything related. I know because i am subscribed to all relevant mailing lists and still fail to catch many moves and changes. Only when stuff fails to compile i notice. Mike -- Michael Jansen http://michael-jansen.biz
Re: KDE/4.11 branched what to do with kde-workspace?
On Mittwoch, 10. Juli 2013 15:34:43 CEST, Michael Jansen wrote: Because of that it should be announced. BIG TIME. I'd suggest to keep master as it is and develop PWv2 in a new branch. Those who want to develop on or use it will hopefully find it and others can continue to use master as it is. (And where important bugfixes etc. for 4.12 can go) Maybe have a git hook to limit write access to master to a fistful of developers to ensure nobody accidentally pushes features there instead into PWv2. Announcing policy anywhere (mygreat.blog - yeah, dot.kde, k-c-d) but through controlling it by code will fail for sure. kde-workspace has far more and more casual commiters than kdelibs. One of us will stumble. Cheers, Thomas
Re: KDE/4.11 branched what to do with kde-workspace?
El Dimecres, 10 de juliol de 2013, a les 15:55:01, Thomas Lübking va escriure: On Mittwoch, 10. Juli 2013 15:34:43 CEST, Michael Jansen wrote: Because of that it should be announced. BIG TIME. I'd suggest to keep master as it is and develop PWv2 in a new branch. Those who want to develop on or use it will hopefully find it and others can continue to use master as it is. (And where important bugfixes etc. for 4.12 can go) But there's not going to be a kde-workspace 4.12 as announced a while ago. Cheers, Albert Maybe have a git hook to limit write access to master to a fistful of developers to ensure nobody accidentally pushes features there instead into PWv2. Announcing policy anywhere (mygreat.blog - yeah, dot.kde, k-c-d) but through controlling it by code will fail for sure. kde-workspace has far more and more casual commiters than kdelibs. One of us will stumble. Cheers, Thomas
Re: KDE/4.11 branched what to do with kde-workspace?
On Mittwoch, 10. Juli 2013 21:58:34 CEST, Albert Astals Cid wrote: Those who want to develop on or use it will hopefully find it and others can continue to use master as it is. (And where important bugfixes etc. for 4.12 can go) But there's not going to be a kde-workspace 4.12 as announced a while ago. No idea what's announced but that's silly and will just cause confusion downstream - we also have kdelibs 4.10 atm and 4.11 soon while technically that's still 4.7 or whatever. There'll have to be (minor) patches to kde-workspace (you cannot keep shipping known and fixable crashes), thus new tarballs and shipping kdelibs 4.13.2, workspace 4.11.12 (depending on kdelibs 4.13.2) and kde-runtime 4.13.2 does not sound very reasonable to me. Cheers, Thomas
Re: KDE/4.11 branched what to do with kde-workspace?
On Mittwoch, 10. Juli 2013 22:39:01 CEST, Scott Kitterman wrote: I thought you said in the 3 month release cycle discussion that every module I think this discussion in unrelated to the new release cycle thread. Frozen workspace and the question what to do with the branches in kde-workspace is real! now! ;-) Cheers, Thomas
Re: Re: KDE/4.11 branched what to do with kde-workspace?
On Wednesday 10 July 2013 22:39:29 Thomas Lübking wrote: On Mittwoch, 10. Juli 2013 21:58:34 CEST, Albert Astals Cid wrote: Those who want to develop on or use it will hopefully find it and others can continue to use master as it is. (And where important bugfixes etc. for 4.12 can go) But there's not going to be a kde-workspace 4.12 as announced a while ago. No idea what's announced but that's silly and will just cause confusion downstream - we also have kdelibs 4.10 atm and 4.11 soon while technically that's still 4.7 or whatever. There'll have to be (minor) patches to kde-workspace (you cannot keep shipping known and fixable crashes), thus new tarballs and shipping kdelibs 4.13.2, workspace 4.11.12 (depending on kdelibs 4.13.2) and kde-runtime 4.13.2 does not sound very reasonable to me. I expected that we would just tag 4.12.0 and so on from the 4.11 branch. Whether it's master or branch doesn't really matter. I agree that this is something we learned from kdelibs that we need to keep the releases going even if they do not contain new features. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: KDE/4.11 branched what to do with kde-workspace?
On Tuesday 09 July 2013 18:57:41 Albert Astals Cid wrote: So the kde-workspace dudes decided they don't want a 4.12 release and that they'll do a LTS 4.11, fine, how do we fix that branch wise? I don't see how that affects branching. * 4.11 is branched from master * master is opened for feature development and will lead to Plasma Workspaces 2 (or whatever the release will be called in the end). If someone wants to do a 4.12 release from kde-workspace module it can be branched from the 4.11 branch. Cheers Martin
Re: KDE/4.11 branched what to do with kde-workspace?
On Tuesday, July 09, 2013 11:45:39 PM Martin Graesslin wrote: * master is opened for feature development and will lead to Plasma Workspaces 2 (or whatever the release will be called in the end). Does this mean that kde-workspace in master will exists, but with a different content (and I assume unstable)? Does it mean the KDE 4.11 branch of kde-workspace will be needed even for master users (or for KDE 4.11)? Andras
