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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
