[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-26 23:40:13
Message-ID: CAJVyKoHEJBpnDsAonKOugJ4J_jju9aZh6-=9bNp8ndWNWZ3Cuw () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Imho this is a good strategy for the 1%, for those applications that need
heavy re-factoring in order to work or make proper use of Qt5 (Plasma and
KWin), however I'm still not convinced that this is a good strategy for the
other 99%.

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.

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, or KDE 4.0 effect (lot of untested changes).

I'd like to propose one of these two options:
-We split Plasma and KWin in separate repos, we freeze them.
-We freeze kde-workspace/runtime and if you want to develop anything you
have to split it.

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.

This will make the transition to a more splited kde-workspace something
gradual, done step by step and organically, no stress for developers, no
stress for packagers, maybe bit more work for release team though.

Cheerz.

[Attachment #5 (text/html)]

<div dir="ltr"><div style>Imho this is a good strategy for the 1%, for those \
applications that need heavy re-factoring in order to work or make proper use of Qt5 \
(Plasma and KWin), however I&#39;m still not convinced that this is a good strategy \
for the other 99%.</div> <div style><br></div><div class="gmail_extra">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.</div> <div class="gmail_extra"><br></div><div \
class="gmail_extra">Besides that, there are a few areas where we&#39;ll see \
development possibly beyond 4.11 like powerdevil, nepomuk, and some kcm&#39;s. \
Holding these changes until PW2 could result in a series of bad side effects like \
loosing manpower, or KDE 4.0 effect (lot of untested changes).</div> <div \
class="gmail_extra"><br></div><div class="gmail_extra" style>I&#39;d like to propose \
one of these two options:</div><div class="gmail_extra" style>-We split Plasma and \
                KWin in separate repos, we freeze them.</div><div class="gmail_extra" \
                style>
-We freeze kde-workspace/runtime and if you want to develop anything you have to \
split it.</div><div class="gmail_extra" style><br></div><div class="gmail_extra" \
style>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.</div> <div class="gmail_extra" style><br></div><div \
class="gmail_extra" style>This will make the transition to a more splited \
kde-workspace something gradual, done step by step and organically, no stress for \
developers, no stress for packagers, maybe bit more work for release team \
though.</div> <div class="gmail_extra" style><br></div><div class="gmail_extra" \
style>Cheerz.</div></div>



_______________________________________________
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]