KDE/4.11 branched what to do with kde-workspace?

[Aaron J. Seigo]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130715/28ecee88/attachment.sig>