[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: Release Strategy Proposal
From:       Àlex Fiestas <afiestas () kde ! org>
Date:       2013-04-28 16:46:57
Message-ID: 1781535.zOhPKNcAC5 () monsterbad
[Download RAW message or body]

On Saturday 27 April 2013 10:11:59 Aaron J. Seigo wrote:
> On Saturday, April 27, 2013 01:40:13 =C0lex 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. the=
re
> are QML-ifications that need to be finished, there are libraries that bec=
ome
> 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 w=
ill =

affect the majority of the code it won't affect the majority of the project=
s 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 th=
at
> in, too.
If we do stable releases every month that will not be enough time to test t=
he =

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 stab=
le
> 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 see=
n a =

lot of progress in kcm's outside (that should be inside) like kscreen, colo=
r =

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 hav=
e 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 bea=
cuse =

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=FCrnberg, 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) contain=
ing
> > 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.
_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
[prev in list] [next in list] [prev in thread] [next in thread]