Re: Splitting kde-workspace and kde-runtime proposal

2014-01-27 Thread David Edmundson
There is an existing page about slitting runtime here:
http://community.kde.org/Frameworks/Epics/New_Runtime_Organization

linked to from http://community.kde.org/Frameworks/Epics

Alex's wiki page looks far more populated.
We should make sure we avoid wiki duplication.

David


Re: Splitting kde-workspace and kde-runtime proposal

2014-01-23 Thread andrea diamantini
I don't clearly understand why KUriFilter-Plugins should go to plasma-
workspace. I noticed KUriFilter is defined in kio and its plugins are used
e.g. in kparts (browserextension). Shouldn't these go to kio?


2014/1/22 Kevin Ottens er...@kde.org

 On Tuesday 21 January 2014 12:05:26 Antonis Tsiapaliokas wrote:
   1) Create two different groups named plasma-workspace and
   plasma-desktop like frameworks
   2) Split out every component into individual repos
   3) Assign repos to the related group.
  
   Advantages:
  
   1) Easy to assign maintainer to individual component.
   2) If we split only some repos, we can not mark it as part of
   workspace but this way we can do it.
   3) More, may be?
  
   That's my humble suggestion. :)
  
Again, this is a proposal so please! send any feedback you might
 have.
  
   Thanks!
 
  I think that splitting each individual component to its own repo might
 be a
  bit confusing. Because if we don't have two groups (plasma-desktop and
  plasma- workspace), then we will not be able to provide something as a
  standard solution. So each person will consider  Plasma Desktop as
  something entirely different.

 Note however that it's not a proper argument for splitting repos or not
 since
 nowadays our infrastructure has the concept of grouping independently of
 the
 repos. So we could split in their own repo and still have a way to make a
 plasma-desktop and a plasma-workspace group.

 OTOH Sebas argument is much more compelling.

 Regards.
 --
 Kévin Ottens, http://ervin.ipsquad.net

 KDAB - proud supporter of KDE, http://www.kdab.com




-- 

Andrea Diamantini
WEB: http://www.adjam.org

rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq@freenode


Re: Splitting kde-workspace and kde-runtime proposal

2014-01-22 Thread David Hubner
 In the plasma sprint we have done a session to plan what we are going to do
 with kde-workspace/kde-runtime repositories, here is the proposal we came
 with.
 
 We are going to create 2 new repos called plasma-desktop and
 plasma-workspace, we decided to use plasma as a prefix so in the future we
 can have more workspaces and desktops without being in the awkward
 situation of having one wrongly labeled as KDE while others are not
 (thinking on for example having Razorqt/lxde as part of KDE in the
 future). Current kde-workspace and kde- runtime will be kept for history
 reasons.
 
 plasma-desktop will hold all specific pieces tied to the desktop
 experience, for example the touchpadenabler only makes sense on laptops.
 
 plasma-workspace will contain all bits that are generic enough to be of
 interest for more than one form factor, for example we need appmenu in
 both, tablet and desktop.
 
 Additionally we want to split optional dependencies (kinfocenter for
 example) and other projects that are quite big.
 
 Some of the new repositories we want to create are:
 powerdevil
 kwin
 oxygen (containing a full Oxygen experience)
 ksysguard
 kinfocenter
 klipper...
 
 A full list of the proposed new repositories can be found at [1].
 
 Finally some other bits could be merged with some Frameworks, it is the
 case for example of solid-hardware and solid-networkstatus that should be
 moved to solid.
 
 Again, this is a proposal so please! send any feedback you might have.
 
 Cheers.

Hi, 

I am ok with splitting KInfocenter into it's own repo. It might also be an 
idea to split System Settings kcm's and KInfocenter kcm's into a repo called 
KCM or something and then have KInfocenter and System Settings repo's just for 
the app. 

I feel I might be missing some history here though.. why is this being done?

Thanks

 
 [1] http://community.kde.org/Plasma/Tokamak7/split_proposal


Re: Re: Splitting kde-workspace and kde-runtime proposal

2014-01-22 Thread Martin Gräßlin
On Tuesday 21 January 2014 13:12:58 David Hubner wrote:
  In the plasma sprint we have done a session to plan what we are going to
  do
  with kde-workspace/kde-runtime repositories, here is the proposal we came
  with.
  
  We are going to create 2 new repos called plasma-desktop and
  plasma-workspace, we decided to use plasma as a prefix so in the future we
  can have more workspaces and desktops without being in the awkward
  situation of having one wrongly labeled as KDE while others are not
  (thinking on for example having Razorqt/lxde as part of KDE in the
  future). Current kde-workspace and kde- runtime will be kept for history
  reasons.
  
  plasma-desktop will hold all specific pieces tied to the desktop
  experience, for example the touchpadenabler only makes sense on laptops.
  
  plasma-workspace will contain all bits that are generic enough to be of
  interest for more than one form factor, for example we need appmenu in
  both, tablet and desktop.
  
  Additionally we want to split optional dependencies (kinfocenter for
  example) and other projects that are quite big.
  
  Some of the new repositories we want to create are:
  powerdevil
  kwin
  oxygen (containing a full Oxygen experience)
  ksysguard
  kinfocenter
  klipper...
  
  A full list of the proposed new repositories can be found at [1].
  
  Finally some other bits could be merged with some Frameworks, it is the
  case for example of solid-hardware and solid-networkstatus that should be
  moved to solid.
  
  Again, this is a proposal so please! send any feedback you might have.
  
  Cheers.
 
 Hi,
 
 I am ok with splitting KInfocenter into it's own repo. It might also be an
 idea to split System Settings kcm's and KInfocenter kcm's into a repo called
 KCM or something and then have KInfocenter and System Settings repo's just
 for the app.

That might be an idea. Or throw together system settings, kinfocenter and all 
the KCMs. But that are details for when we do the split :-)

 
 I feel I might be missing some history here though.. why is this being done?

The idea to split workspace into more repos had been around for quite some 
time. We noticed that we have applications with very different scope in kde-
workspace. Historically the workspace has been X11 only and everything in the 
repo should only make sense when running the KDE workspaces. That's not really 
the case any more:
* we have applications which are built on all platforms (e.g. KInfoCenter)
* we have X11 only applications which are used outside the KDE workspaces 
(e.g. KWin)
* we have applications which are only used on one or the other shell of the 
kde-workspaces
* we have libraries other applications depend on and we don't want 
applications to depend on the workspaces (famous example kdevelop depending on 
ksysguard)

Just look at the CMakeList and the mess we do with finding the requirements 
for e.g. KWin. Let's first find some random X11 library to check whether we 
are on X11 and then turn the optional X11 dependency into a mandatory and 
start to find more required stuff. That's IMHO already a good enough technical 
reason to do the split.

There are more reasons to split up and clean up. I just wanted to outline one 
rather obvious.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.


Re: Splitting kde-workspace and kde-runtime proposal

2014-01-21 Thread Sebastian Kügler
On Tuesday, January 21, 2014 11:03:57 Bhushan Shah wrote:
 On Tue, Jan 21, 2014 at 1:19 AM, Àlex Fiestas afies...@kde.org wrote:
  In the plasma sprint we have done a session to plan what we are going to
  do
  with kde-workspace/kde-runtime repositories, here is the proposal we came
  with.
  
  We are going to create 2 new repos called plasma-desktop and
  plasma-workspace, we decided to use plasma as a prefix so in the future
  we can have more workspaces and desktops without being in the awkward
  situation of having one wrongly labeled as KDE while others are not
  (thinking on for example having Razorqt/lxde as part of KDE in the
  future). Current kde-workspace and kde- runtime will be kept for history
  reasons.
 
 I want to suggest something different,
 
 1) Create two different groups named plasma-workspace and
 plasma-desktop like frameworks

How is this granularity useful? To me, it sounds like way too much, too hard 
to move code around within the same domain, for example. We don't want to 
flood people with hundreds of repositories.

The generic workspace vs. specific formfactor split is well in line with how 
we see people deploying Plasma, you install the framework, the generic 
workspace, and then a package for a specific formfactor.

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9


Re: Splitting kde-workspace and kde-runtime proposal

2014-01-21 Thread Antonis Tsiapaliokas
 1) Create two different groups named plasma-workspace and
 plasma-desktop like frameworks
 2) Split out every component into individual repos
 3) Assign repos to the related group.
 
 Advantages:
 
 1) Easy to assign maintainer to individual component.
 2) If we split only some repos, we can not mark it as part of
 workspace but this way we can do it.
 3) More, may be?
 
 That's my humble suggestion. :)
 
  Again, this is a proposal so please! send any feedback you might have.
 
 Thanks!

I think that splitting each individual component to its own repo might be a 
bit confusing. Because if we don't have two groups (plasma-desktop and plasma-
workspace), then we will not be able to provide something as a standard 
solution. So each person will consider  Plasma Desktop as something entirely 
different.


Re: Splitting kde-workspace and kde-runtime proposal

2014-01-21 Thread Bhushan Shah
Hello!

On Tue, Jan 21, 2014 at 1:19 AM, Àlex Fiestas afies...@kde.org wrote:
 In the plasma sprint we have done a session to plan what we are going to do
 with kde-workspace/kde-runtime repositories, here is the proposal we came
 with.

 We are going to create 2 new repos called plasma-desktop and plasma-workspace,
 we decided to use plasma as a prefix so in the future we can have more
 workspaces and desktops without being in the awkward situation of having one
 wrongly labeled as KDE while others are not (thinking on for example having
 Razorqt/lxde as part of KDE in the future). Current kde-workspace and kde-
 runtime will be kept for history reasons.

I want to suggest something different,

1) Create two different groups named plasma-workspace and
plasma-desktop like frameworks
2) Split out every component into individual repos
3) Assign repos to the related group.

Advantages:

1) Easy to assign maintainer to individual component.
2) If we split only some repos, we can not mark it as part of
workspace but this way we can do it.
3) More, may be?

That's my humble suggestion. :)

 Again, this is a proposal so please! send any feedback you might have.

Thanks!

-- 
Bhushan Shah

http://bhush9.github.io
IRC Nick : bshah on Freenode


Re: Splitting kde-workspace and kde-runtime proposal

2014-01-21 Thread Bhushan Shah
Hello!

On Tue, Jan 21, 2014 at 3:35 PM, Antonis Tsiapaliokas kok...@gmail.com wrote:
 I think that splitting each individual component to its own repo might be a
 bit confusing. Because if we don't have two groups (plasma-desktop and plasma-
 workspace), then we will not be able to provide something as a standard
 solution. So each person will consider  Plasma Desktop as something entirely
 different.

Yes having group is essential, otherwise it will create confusion..
repo like kde:kf5umbrella will be also needed.

Thanks!

-- 
Bhushan Shah

http://bhush9.github.io
IRC Nick : bshah on Freenode


Re: Splitting kde-workspace and kde-runtime proposal

2014-01-21 Thread Marco Martin
On Tuesday 21 January 2014 13:04:22 Sebastian Kügler wrote:
  1) Create two different groups named plasma-workspace and
  plasma-desktop like frameworks
 
 How is this granularity useful? To me, it sounds like way too much, too hard
 to move code around within the same domain, for example. We don't want to
 flood people with hundreds of repositories.
 
 The generic workspace vs. specific formfactor split is well in line with how
 we see people deploying Plasma, you install the framework, the generic
 workspace, and then a package for a specific formfactor.

just instinctively i would say that the more splitting the more not my 
problem, i'll ignore this bit scenario it may cause

-- 
Marco Martin