repositories beyond kde-workspace

[Aaron J. Seigo]

hi..

as Alex noted in an email in the "reflecting on 4.10" thread, we have several 
current and upcoming git repos that are topically part of the workspaces. such 
repositories include:

* bluedevil
* networkmanagement
* kscreen (it's dependency, libkscreen, is probably a Frameworks topic, not 
workspace)
* kio_mtp (we used to stuff these things in kde-runtime. that's going away with 
Frameworks)
* lightdm

and more ar coming, such as accounts. so it's going to get more complex rather 
than less.

the question we have is:

	how do we want to bring these various repositories together
	into a coherent, usable result?

we don't need one univeral answer for all the repositories. we could say: 
let's create a general KIO slave repo and put kio_mtp in there along with the 
rest of the ones in kde-runtime (or even create a kioslave-core and a 
kioslave-extras or some such), and do something completely different for the 
rest.

the question can also be further broken down into the following:

* where should the repositories live? 
	* 1 place, such as a single "workspaces" topic on projects.kde.org
	* scattered: some in kde-workspaces and some in extragear/base (and 
elsewhere)
	* ??

* what should the devel strategy of these repositories be?
	* a shared time based cycle for all, or each repo sets its own time based 
cycle?
	* a single development strategy (such as branch -> integration -> 
master), or a small # of defined strategies to pick from; or leave it up to 
each repo?
	* ??

* what should the release cycle of these repositories be?
	* each repo releases when it wants, no coordination
	* repos release as they wish, with SC releases that contain the current 
stable versions of all the workspace repos
	* all release with the big SC releases
	* ??

* how do we want to coordinate on direction, strategy, needs, overall 
composition, etc?



to put these questions into a shared frame of reference, we could also ask 
ourselves what our goals are in thinking about all these repositories 
together:


Are we making a product or a toolbox? e.g.:

* a set of individual components and tools that downstreams assemble 
into working products

* a working product that can be placed on top of a given OS, where 
we work on how the parts should preferabbly be assembled and deliver them that 
way in releases

* something in between the above


Shared or individual vision?

* do we work together on a shared development plan and goals, with all work in 
all repositories in support of this

* each repository / component develops it's own plan and goals, and we (or 
some subset of us) try to coordinate all of that into a sensible whole

* we communicate while we develop, and trust that will be enough to bring 
harmony between our different plans, goals, etc.


What attributes in our products do we aim for?

(I'll leave this one without a list of possibilities, as it would simply be 
too leading to do so ..)


(I'll post my personal answers in a reply to this email as well ...)

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130114/f0407537/attachment.sig>