Release Strategy Proposal

[Aaron J. Seigo]

On Saturday, April 27, 2013 01:40:13 Àlex Fiestas wrote:
> We could apply the same argument we can use for applications to most of
> kde-workspace and kde-runtime, their port to Qt5 will be mostly execute a
> script and use KDE4support.

firstly, this is not about kde-runtime (at least not for me). that is a shared 
module and while we will cease feature work in the plasma/ subdirectory, but 
the rest can continue on as-is afaic.

kde-workspace, hwoever, needs rather more than simply porting to Qt5. there 
are QML-ifications that need to be finished, there are libraries that become 
obsolete, there are entire applications that will disappear (e.g. kdm), there 
are session startup mechanisms that need changing, etc. some parts of kde-
workspace will indeed work with a simple "make it compile" port, but that is 
the smallest amount of work and affects the minority of the code in kde-
workspace.

one more complication is that the moment we split libraries out into a 
separate repo, we are making commitments to API and ABI compatibility for all 
the other things that will come to rely on them.

> Besides that, there are a few areas where we'll see development possibly
> beyond 4.11 like powerdevil, nepomuk, and some kcm's. Holding these changes
> until PW2 could result in a series of bad side effects like loosing
> manpower,

let's use common sense, then.

if nepomuk sees changes that require application porting, then something is 
going wrong with nepomuk development as it should keep a stable interface. but 
lets say that this happens anyways. then we fix up kde-workspace 4.11.x since 
that would be an obvious bug fix.

if there work in powerdevil that addresses shortcomings in the current system 
that are compelling enough for the user experience, we can fold that in, too.

kcm's would be a more difficult issue since that would involve changing strings, 
something our translators obviously do not like us doing in stable release 
branches. i imagine you bring up kcm's because you expect them to change in 
relation to powerdevil rewrites. i can see how they could definitely be 
improved, but i also don't see why they need to be change urgently.

btw, given the lack of work on kcm's in the last couple of years, i find it 
particularly galling that you suggest that we'd lose manpower there by moving 
forward on PW2 where we actually have people working actively.

in any case, if your plan was to have these changes in 4.11, then it isn't a 
problem. all of this can go in.

if your plan was to have these changes in 4.12, then it is also not a huge 
problem since the reason we're making this change *now* is so that we have a 
chance of getting out a PW2 release sometime around when 4.12 would come out.

what i'm not OK with is delaying the entire PW2 effort for powerdevil (e.g.)

> or KDE 4.0 effect (lot of untested changes).

i fail to see the parallel.

> I'd like to propose one of these two options:
> -We split Plasma and KWin in separate repos, we freeze them.

kwin is fairly self-contained. what a "plasma repo" would look like is 
anything but obvious. we spent time on this last week in Nürnberg, and until 
we start porting things we are not going to know which libraries will be kept 
in what form under kde-workspace/libs/ nor which parts under plasma/ will need 
to be kept.

we do know that the shells binaries are going away; we do know that the 
separation based on shell type for applets, etc. is going away; so we have 
some answers, but they are incomplete.

there are also things such as ksmserver and krunner which also need to undergo 
some transformations, some of which are well defined now and some of which 
aren't. 

splitting kde-workspace now will result in premature decision making that we 
will likely pay for.

for these reasons, this gets a -1 from me.

> -We freeze kde-workspace/runtime and if you want to develop anything you
> have to split it.

for the same reasons as above, this doesn't help much. it just makes 
everything more difficult and forces decisions on us we are not in a place to 
make with all the information we need.

otherwise, this is not much different from the original proposal:

* having a 4.11 branch in kde-workspace is the same as freezing kde-workspace.
* as we modify kde-workspace into PW2, we split things into separate 
repositories as it makes sense to do so
 
> This proposal is based on a discussion we had in plasma-devel where most
> developers there (iirc was consensus) agreed that in the future
> kde-workspace should be a meta-repository (like extragear/base) containing
> all the repos needed to have a workspace, for example current repos like
> bluedevil, plasma-nm or print-manager should be included.

yes, this is the goal we're working towards. we also do not know what a split 
kde-workspace will look like right now, and forcing it right now risks us 
making some very bad decisions that will cause much more work in future.
 
> This will make the transition to a more splited kde-workspace something
> gradual, done step by step and organically,

step-by-step and organically would be to process the split of kde-workspace as 
we know the shape of PW2.

> no stress for developers, no
> stress for packagers, maybe bit more work for release team though.

this would be quite a bit more stressful for myself. i imagine i'm not the 
only one, either.

-- 
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/release-team/attachments/20130427/239cddcc/attachment.sig>