repositories beyond kde-workspace

Martin Gräßlin mgraesslin at kde.org
Tue Jan 15 12:37:09 UTC 2013


On Monday 14 January 2013 17:51:50 Aaron J. Seigo wrote:
> * 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)
> 	* ??
IMHO it should all be in workspace on pko. If we drop out of the SC (and given 
some comments on the threads, that seems to be common agreement) we don't need 
extragear anymore for workspace stuff.
> 
> * 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?
Mixed: new components should be allowed to do intermediate releases. But all 
should follow the same cycle (that is release at a common day PW2, PW3, 
PW4...)
> 	* 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?
to work on it, it would be better to have a common strategy
> 	* ??
> 
> * 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
> 	* ??
see answers above.
> 
> * how do we want to coordinate on direction, strategy, needs, overall
> composition, etc?
I would like to see:
* goals being written down (cko)
* for communication a dedicated (low traffic, no review requests) mailing list 
everybody is subscribed to working on the workspaces.
* sprints
* IRC meetings
> 
> 
> 
> 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
clearly second one (working product). I think we don't want distributions to 
combine. And it's probably much easier if we define the product than to expect 
each distribution to do it.
> 
> * 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
this one
> 
> * 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.
given the last cycle I think we need to communicate more and better
> 
> 
> What attributes in our products do we aim for?
PW are an easy to use, but flexible workspace for Linux based systems. PW is 
designed to go out of the way; users should not notice that they are using a 
workspace at all. Nevertheless PW provides a steep learning curve for advanced 
users, which are available, if they do not conflict with the primary mission.

This is the KWin mission statement adjust for Plasma Workspaces.

Cheers
Martin
-------------- 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/74e036fb/attachment.sig>


More information about the Plasma-devel mailing list