Release Strategy Proposal

[Àlex Fiestas]

On Saturday 27 April 2013 10:11:59 Aaron J. Seigo wrote:
> 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.
First then we have to decide what we are going to freeze, it is only kde-
workspace I take?

> 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.
And we don't need to wait until Qt5/KF5 to do most of that, and while Qt5 will 
affect the majority of the code it won't affect the majority of the projects 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.
We don't really need to keep ABI/API, but I agree that splitting libraries is 
a mess.

> > 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.
I was refering to the nepomuk folder in kde-runtime, since according to you 
kde-runtime won't be included in this freeze there is nothing to talk about 
this.

> 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.
If we do stable releases every month that will not be enough time to test the 
changes that Powerdevil needs, no way we can get this changes in without 
testing.
> 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.
The reason why I mentioned KCM is because a new synaptik kcm is going to be 
written, some are going to be removed (krandr) or improved (Removable 
Devices).

> 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.
We have not seen movement in the kcm's within kde-workspace but we have seen a 
lot of progress in kcm's outside (that should be inside) like kscreen, color 
management, bluetooth, network...
> 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.
I don't really see why freezing powerdevil (for example) will speed up the 
process in PW2.

> what i'm not OK with is delaying the entire PW2 effort for powerdevil (e.g.)
what I'm not Ok with is waiting until PW2 is ready to do big changes in 
powerdevil. I also don't want to have pressue to put stuff in 4.11 just beacuse 
there won't be a 4.12
> > or KDE 4.0 effect (lot of untested changes).
> 
> i fail to see the parallel.
If we hold all the changes we want to do in kde-workspace NOT related in 
anyway to Qt5/KF5 for when PW2 releases, those changes will pile up to the 
ones required for Qt5/KF5 porting, having lot of untested changes being 
released with PW2.

> > 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.
Well it is quite different, in the first option you are the ones having to make 
premature decisions, in the second option only the interested parties will 
have to get their hands dirty. Good example of this will be splitting 
PowerDevil.

> 
> 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.
The risk depends on what is proposed to be splitted.