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

[Aaron J. Seigo]

On Monday, July 15, 2013 20:00:39 Thomas Lübking wrote:
> But KDE has ever released as block and so far still releases as block.

this is a non-argument. otherwise we will forever keep the SC together exactly 
as it is. flexibility can be useful.

> If now ppl. get "mostly block and some bits of old block" that is far more
> confusing to them than always combining linux 2.4 and XR11v6 - or after a
> clear split (now) be fine about xorg stuff ranging from 1.04 to 1.14.2
> 
> You can expect "wrong" use of version tags, failing scripts and just poor
> users sitting in front of packages.ubuntu.com, searching for the proper
> package.

what scripts will fail?

version tags, by which i assume you mean in bugzilla: more and more of our 
reports come from dr. konqi, which gets it right. that said, if someone files a 
bug against anything in kde-workspace says they are using “version 12.2” it 
doesn’t take a brain surgeon to figure it out that they are using 11.x of kde-
workspace. so that’s a none-issue.

people starting at software.opensuse.org or whatever, i don’t care. most 
people use the updater and it gives them what it gives them.

> Also there will very likely be bugfixes suitable for some 4.11.x and
> bugfixes only suitable for a 4.12.0/4.13.0 release.

please provide a concrete example.

> That means you will either
> a) threaten users with patches in minor releases that would normally have
> gone into major ones b) expect patch submitters to hold back their patch
> until 4.11 will no more tag 4.11.6 but the next one will be 4.12 c)
> introduce a tic-toc release for kde-workspace (advising conservatve distros
> to skip the odd ones, so "risky" patches are more tested for the even ones)
> d) draw something else out of your magic hat.

this is a false choice. none of those options will be taken. if a bug fix is 
not proven enough to go into a 4.11.x release, it doesn’t belong as a bug fix.

if a massive change comes along that can threaten stability, we need to 
measure it based on how critical it is that change is in THAT release.

we are sometimes too afraid to support “old” software, even though that is 
what our users are using in reality. we want to constantly update it and push 
it to everyone’s machines. and that’s precisely what we don’t want to be doing 
here.

during 3.5.x we had a few changes that were pretty big that went in because 
they were pretty much required. they were well tested and it worked out. so we 
have history on our side there.

for any big change that hits that is not a bug fix or can not be introduced 
without causing more chaos than it will possibly fix, we put it into the next 
release (which happens to be PW2).

> As the major conflictive concerns seem that
> a) a PW2 branch cannot be re-merged into master
> b) ppl. will stumble about master being "something else"
> 
> i suggest to branch off PW2 AND 4.xx from current master.
> Then freeze master in a way that makes it unusable for everyone.
> No pushing, and ideally no (re-)checkout either.

which causes multiple problems, all of which we saw with kdelibs in the last 
year or two.

moreover, if we freeze master in a way that makes it unusable for everyone, 
that is materially no different than just using master for the Qt5 development. 
except that it’s one less rule to remember and one less branch (the Qt5 
focussed one) to manage.

master is where next is developed. that’s been our pattern and it is sensible 
enough.

> On checkout, commit, clone or update attempts either get
> developers/distros/users a message, or (in case that's absolutely not
> possible) have at least a synthetic commit

instead of all this complexity, however about just using master for 
development of the Qt5 version so that the build doesn’t work when you point 
it at a Qt4/KDE libs 4.x version?

> This way you'll maintain a clean "master -> PW2" history, no merge problem.
> otoh you prevent any confusion about the nature of master *by git rules* and
> not some blog entry or whatever "big time" annoucenments you might have in
> mind, which frankly, and i'm sure you're absolutely aware of this, have
> reliably and more than once proven to completely fail in past incidents.

*sigh*

yes, you’re  right i’m aware that such announcements don't  work. in fact, i 
already pointed in these threads that such things don’t work. as an exercise i 
asked for a list of places that would cover enough audience appropriately so 
that it could work, unlike in the past.

i did that specifically to make the point you just made. so, yes, we agree. 
great.

i also proposed a solution: make the build require qt5/frameworks5.

-- 
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/727ccf32/attachment.sig>