On Saturday, July 13, 2013 23:36:24 David Faure wrote: > I feel strongly about what kde-workspace should do in the current situation, > actually, after having gone through multiple solutions with kdelibs:
Welcome to my world. I feel strongly about what kdelibs should have done. I am not the maintainer, however, and so I mostly put up with being repeatedly ignored out of respect for the role of maintainers within KDE. I think the results were a disaster and I believe it could have largely, perhaps even entirely, been avoided. It’s not the end of the world, however, and Frameworks 5 will turn out well in the end. So please excuse me if I don’t base my thoughts on your input on how to maintain a module. > *Minimize disruption* For whom? Not for the developers (see below). Not for our users (a well maintained 4.11 Plasma Desktop is far less disruptive). The disruption you mean is for those who build from source, from git master without tracking what’s going on. Fair enough, they are people too :) For those using tools like kdesrc-build, I think there is a possible answer (see below) However, I don’t think the disruption to these people will be anything like kdelibs: Unlike kdelibs, kde-workspace master won’t build against 4.x. it’s pretty obvious that something is not right if the module doesn’t build; nobody is going to patch a module they can’t build. Unlike kdelibs, which pretty much everyone relies on for their applications, nobody relies on kde-workspace to build their apps. 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. Ergo, the disruption is likely to be small, and we’ll do our best to keep it that way. > * 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. 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. > * 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! 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! > 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. ... which is why we don’t want a frameworks branch! > Really: "master" is not "where most developers work". master is: the latest That’s already how we treat master, yes. > 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? > 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. Thanks, but that isn’t what we’re trying to avoid. 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. We’re trying to avoid having to alter the workflow of the developers involved in writing the actual code. > Minimizing surprises also means doing exactly what kdelibs is now doing > (forget about the initial plan, it failed). Yes, it failed. The question is whether it was due to the idea itself being flawed or the implementation of it. I know that a common trap is to think that an idea failed just because the implementation wasn’t good enough .. and THIS time we’ll do it right (only to repeat the failure) However, in this case, I can point to numerous things wholely unrelated to the idea itself that led to various aspects of the failure. I don’t think that discussion is particularly on-topic here, but if you want to discuss it I’m happy to do so elsewhere. > 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. The same lovely mess that kdelibs put itself in? No thanks. > 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. It’s the later merging back into master and the ongoing branch management that is the problem, not this. We have enough people to manage one 4.x branchand do frameworks. We have a number of modules in extragear (and even one or two still in playground, unfortunately) that we have to track with these changes for Plasma Active. (We’re addressing that inneficiency in Plasma Workspaces 2, btw.) The branch housing the frameworks work will nearly immediately become all but unmergable with 4.x branches: directories will be moving, large numbers of files going away, lots of new files being added, huge changes to significan portions of the the code bases. This is fine as long as the parent branch never changes after we branch for frameworks 5, which would mean a master just sitting there that you can’t touch which causes even more confusion than the alternatives; not even rebasing could help us even if git.kde.org allowed it. So instead of having something unmergable at the end of it all or having a locked down master branch, we’re just going to use master for that work. (Well, branches will contain the work as it is ongoing, but those will be merged down into master as they complete their topic.) This is also something we have the manpower to do, and do well. -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.
