repositories beyond kde-workspace

[Marco Martin]

On Monday 14 January 2013, Aaron J. Seigo wrote:
> 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?

most of them are projects of quite different, so it's a bit difficult

i see it either one repo each, or again a big repo that catches all.
the latter probably goes in a different direction of frameworks and latest 
efforts of more modularity (also, if they end up in the same repo, should be 
clear that they can't depend each other for building)

about single repository, i think it should be kde-workspace rather than a new 
one.

If with kdesrc-build building becomes seamless enough, i vote for separate 
repo, suynchronized release.

> 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.

for the things that are plugins, makes sense and i like it, just like 
kdeplasma-addons

for libraries, some other solution is needed

> * 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 me, any repo layout strategy is adopted the real important thing is 
encouraging collaboration as much as possible, and adopt a workflow that 
discourages as much as possible each small project becoming isolate.

That's the reason i think the development cycle should be the same for all of 
them, so their nev versions would be released only in sync with SC.

ideally all of them would adopt the alwys stable master philosophy, but i 
think a freeze period in which no feature branches are merged anymore would 
stay similar to now.


> 
> 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?

I see ourselves making a single, big product.
a product that has an important technical detail, being made of many small 
parts that should be possible for 3rd parties use just one of those parts, but 
we should not forget the big, composite picture

> 
> What attributes in our products do we aim for?
> 

quality, both in the single parts and in the whole picture, continuity of 
design, (elegance? ;)

we should aim to make many small individual pieces that one wants to use 
together, in the whole product form, not because otherwise don't work well, 
but because each part is the best in their respective fields, and when put 
together just have an image of continuity that is hard to renounce to.

Cheers,
Marco Martin