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

[Aaron J. Seigo]

On Monday, July 15, 2013 10:15:10 Michael Pyne wrote:
> On Mon, July 15, 2013 12:27:53 Aaron J. Seigo wrote:
> > On Saturday, July 13, 2013 23:36:24 David Faure wrote:
> > 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

correct.

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

then it gets complicated in a different way. we are suppoting 4.11 for an 
extended time period (2 years) so downstreams can have a version they commit 
to while we work on Plasma Workspaces 2. goal: no user disruption by giving 
downstreams an attractive 4.x version of Plasma Desktop to use while they wait 
for PW2.

so let’s say a downstream picks 4.11 for extended time distribution (SLED, 
RHEL, LTS, etc). we stop kde-workspace 4.11.x with x = 5 and move to 4.12. to 
get the benefits of the ongoing bug-fix-only stabilizatioin, they’ll have to 
ship 4.12 kde-workspace, but stick with 4.11 everything else.

with kdelibs and kde-workspace both frozen, keeping the version number 
consistent (e.g. 4.11.x) even while everything else moves on makes the 
communication clearer (many of our downstreams really rely pedantically on 
version numbers) and will mean they don’t have to invent exceptions/reasons to 
ship a 4.12/4.13 kde-workspace with 4.11 kdelibs on their long-term stable 
release.

most people seem to be thinking about future development and packaging the 
latest and greatest and making everything consistent on the surface. i’m 
thinking about longer term patterns here with factual consistency in the 
version numbers.

i’m not interested in repeating the errors of kdelibs here.

> Perhaps this is more semantically clear though (the reason it's still called
> 4.11.y is that there are still no new features)?

yes; it is semantically clear for downstreams, for developers who may want to 
work on changes there, etc.

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

you’re msising the salient point that we have made a commitment to 2 years of 
bug fix updates of the 4.11 version of kde-workspace. that is not a commitment 
i will go back on. we discussed it extensively with release team, packagers 
and others (inc on this very list) and i’m not about to have it derailed now 
because of this set of tangential issues.

so if there is a 4.12 branch, it will:

* be branched from 4.11.x
* receive no updates, including any improvements made in 4.11, unless someone 
steps up to merge 4.11.x continuously into the  4.12 branch
* not be tested by myself, or probably many (if any) others in the workspaces 
team

ditto for 4.13, etc.

put plainly: if you want a 4.12 kde-workspace, you get to fork and maintian 
it.

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

one point of concern, yes.

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

yes. it also allows ut to make it clear that master is not receiving further 
development by tieing it to Qt5/Frameworks5/libplasma2 as a build requirement.

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

yes, this is ~exactly what we’ve already proposed.

we will be doing curated merges. from topic branches. the idea, which we’ve 
trialed already in other repositories successfully, is to minimize disruption 
to as close to zero as possible by having topic branches, a testing or 
integration branch and a master branch. the integration branch comes into play 
when one wants a 2-tier testing system. we won’t need this at first in kde-
workspace as we will not have need for a “always perfectly stable” guarantee 
until some of the initial work is done.

when things settle, we will probably set up an integration branch allowing 
master to be always usable. it worked marvelously for plasma active with a 
very management amount of effort. the only down side is that it takes more time 
for a feature branch to be “done” until the time it is in master. this is not 
fun for the impatient, but they can use the integration branch ;)

the problem with having a master that sits there and does nothing but get 
merges from some other branch that is actually active is:

* it is more work for no extra gain in development
* other developers find it “confusing” (c.f. kdelibs since frameworks devel 
started)

so there is no reason to treat master as anything other than "next"

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

stable is good enough, as 4.11 would be the recommended branch for default 
builds unless one specifically configures it to build the frameworks 5 version

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

that would be fantastic. and/or having a way to mark an error message in a way 
that it is shown directly to the user (rather than be pointed to the log files)

-- 
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/20130716/6a26736f/attachment.sig>