repositories beyond kde-workspace

[Aaron J. Seigo]

On Monday, January 14, 2013 20:54:56 Marco Martin wrote:
> On Monday 14 January 2013, Aaron J. Seigo wrote:
> > 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

well, someone has to do it, right? if we do nothing, distros will have to do 
more work. and they are likely to do it differently.

with networkmanagement, for instance, they already do.

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

yes, i think we can rely on kdesrc-build. i use it for various multi-repos 
now. one of the keys seems to be ensuring build order dependencies are noted 
in the kde-build-metadata repository.
 
> > * 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.

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

i'm a little concerned that this could stunt development of some module, but 
i'll cover that in my reply to the main email in a bit :)
 
> 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

i agree that the components should not become welded together so that people 
can use individual parts to build new things.

to create an actual product out of all these pieces, however, we need to think 
about all the pieces together. we know this first hand from Active ...

> > What attributes in our products do we aim for?
> 
> quality, both in the single parts and in the whole picture, continuity of
> design, (elegance? ;)

+1

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

i agree with this, but then i ask myself: how do we achieve continuity, and 
ensure the pieces work well together? it's one thing to create a bunch of 
individual things that are each quite good ...

-- 
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/20130115/e477e793/attachment.sig>