repositories beyond kde-workspace

[Alex Fiestas]

> * where should the repositories live? 
Each project should be in his own repo but in a way that makes compile it easy 
(./kdesrc-build kde-workspace, done).

> * what should the devel strategy of these repositories be?
> * what should the release cycle of these repositories be?
Whatever fits best to the project maintainers, each project has different 
needs. One of the values I use is whether if it meets user expectations or 
not.

Kio_mtp: It does what it is supposed to do, transfer files (meets user 
expectations). So if we have 6months release cycles with stable releases every 
month, nobody will care.

Networkmanagement: If tomorrow we need to support NFC, WiMAX, newVpn, we need 
to do it as soon as the feature is stable, not 9 month after. User expects to 
connect to the Internet and we CAN NOT FAIL on that.

>* what should the devel strategy of these repositories be?
New projects have other needs like kscreen. Basically until we are really 
stable we need to use Release Soon Release Often.

All these projects should have the same development strategy, but we can only 
have recommendations and it should be up to the maintainer.

-----------------------------------------------------------------------------

In the ideal situation, kde-workspace way of working should be flexible enough 
to accommodate any project, we should not impose directives that will work for
Some projects and won't work for others.

A way of doing this is making kde-workspace a "software compilation" 
(Muahahaha), picking every last stable version.

For doing this and success we have to change our way of working, but surprise! 
We are already going into that direction.

-Development strategy (stable, integration, branches)
-More review based
-Assign new maintainers

Once that's done, make kde-workspace a compilation of software shouldn't be 
difficult at all.

----------------------------------------------------------------------------

Answer to the rest of the questions:
> * how do we want to coordinate on direction, strategy, needs, overall 
> composition, etc?
The collaboration between the projects you mention is excellent, let me put 
some examples:
-Bluetooth/Networkmanagement, make it easy to use your phone to connect to the 
internet
-PowerDevil, Krandr/KSCreen: Inhibit suspension when a monitor is connected
-Lightdm, kscreen: We'll use kscreen to setup better XrandR config in it 
(extend rather than clone with ugly resolutions).
-Lightdm suspends when the lid is closed (well no code is shared here, but 
that is planned in the future).

This happened organically based on discussions we have been having via 
Internet or in Person (sprints, events, Akademy).

Recent history has shown that splitting our community (KDE) in sub-
communities/projects is working quite well (Solid, Calligra, Kdevelop, 
KDEMultimedia, etc) when it comes to every individual projects but it has 
damaged the coordination between them.

These are some ideas I can think of that will help:
- Unified channel of communication between all projects
- Desktop/Active/Workspace sprints (maybe same people, different focus)
- Use Akademy to coordinate between ALL projects (this include KDEvelop, 
Calligra, Frameworks...). What does Calligra want from Plasma for the next 
year? And from Kdevelop? And what wants Kdevelop from Plasma?

The channels of communication should have clear rules for avoiding bullshit 
and offtopic. We must reeducate ourselves.

> Are we making a product or a toolbox? e.g.:
We are making both (unix way).

We are creating the tools that allow us to create the product. We should 
definitively do better in the product creation, spend more time on it.
Imho Active is a good example, you are developing tools (SLC for instance) for 
producing a final product (Active) and you are spending a lot of time doing 
Active itself (integrating everything, testing, creating iso's, quality etc).

> Shared or individual vision?
Shared.

> What attributes in our products do we aim for?
Just works, smooth, usable, simple, coherent, beautiful.

I hope the email is not too messy :p

Cheers and good job initiating this thread.