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

[Michael Pyne]

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