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

[David Faure]

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.

> We’re trying to avoid having to alter the workflow of the developers
> involved in writing the actual code.

Come on, this is really not an argument. Having to compile ECM + Qt5 + KF5 is 
a major setup change, at that point you can surely 'git checkout frameworks', 
how hard can that be.

> 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)

The current kdelibs solution is NOT a failure. It's working pretty well.

> 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.

Yes, let's not discuss the past, let's discuss the present.

> > 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.

THERE IS NO MESS. It's working fine. There's no unexpected surprises, bugfixes 
go to 4.11, i18n changes go to 4.12, frameworks work goes into frameworks.

The mess is what you want to introduce. A different branching scheme in one of 
the KDE SC modules, compared to all others. Suddenly kde-workspace master 
won't work with kdelibs master, nor with any other of the "master" modules.
And in 5 months time, we'll have 60% of the modules where "master" means qt4 
and 40% of the modules where "master" means qt5. *That* is a mess.
 
> It’s the later merging back into master [that is the problem]

What's the issue with "git merge frameworks" in master (on the day of the big 
switch), after a last master->frameworks merge?

> We have enough people to  manage one 4.x branchand do frameworks.

You're repeating the initial-kdelibs-setup mistake. The whole reason for that 
*was* the thinking that 'two branches is enough'. But with git, merging to 
master is trivial, so managing a master branch is trivial.
  
> 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.)

See, suddenly all these modules won't be usable from "master" for KDE 4.12 
anymore. Big mess ahead.

> 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.  

Yes, just like in kdelibs, and this creates work when regularly merging the 
bugfixes from master to frameworks, yes. But it won't create work for the 
final frameworks->master branch, then. Or are you saying that you don't want 
to merge bugfixes from your stable branch to frameworks, ever?

> 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.

If you don't want to merge, then a forced push would still be a better 
alternative IMHO, in the future when we want to switch 'master' to mean 
qt5/kf5 everywhere. Disruption on one particular day only for all of KDE SC, 
rather than progressive disruption in one module after the other, month after 
month, for the next 2 years.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130717/551685ce/attachment.sig>