This section tries to put together some personas for the way developers works. We will then try to ensure that the desired workflows are supported as well as can be achieved in the new setup.

+

+

* the focused developer (e.g. "I work on Kate. Just Kate.")

+

+

Developers following this pattern will most likely find having a module that only contains the application they work on most convenient. This would allow them to easily update their application without pulling in changes from elsewhere in the software stack. That said, for development against the latest versions of the core, they will also need to be able to convenient update kdelibs and kdebase.

+

+

* the fast paced application development team (e.g. "We release a new version of Amarok every 6 weeks.")

+

* hybrid SC-but-also-individual-releases-with-focus-on-specific-targets (e.g. "Marble is part of the KDE Edu module, but also is targetting smart phones in an agressive manner.")

+

* fast paced development driven by external requirements (e.g. "KDE PIM is in practice primarily developed according to the needs and schedules of paying clients.")

+

* tight knit community that co-maintains a set of components/applications (e.g. "All applications in KDE Games are worked on communally by whomever is currently active in the KDE Games team at the time.")

+

+

A team like this will most likely find that a single repo holding the entire module would be most convenient. This would make (for example) applying a fix or new caching model across all applications easier.

+

+

* set of components that share local libraries and only make sense when released together (e.g. "kdebase-workspace hosts several local, non-BIC libraries shared between KDM, KWin, Plasma-* shells and contains all the base plugins required for a reasonably functioning KDE Workspace.")

+

* downstream kde packagers

+

* KDE bleeding edge users/testers

+

+

The situation here should be much the same as before. People using scripts like kdesvnbuild will be able to download and update kde as before. The scripts themselves however will need to be modified to address any new organisation.

This section tries to put together some personas for the way developers works. We will then try to ensure that the desired workflows are supported as well as can be achieved in the new setup.

the focused developer (e.g. "I work on Kate. Just Kate.")

Developers following this pattern will most likely find having a module that only contains the application they work on most convenient. This would allow them to easily update their application without pulling in changes from elsewhere in the software stack. That said, for development against the latest versions of the core, they will also need to be able to convenient update kdelibs and kdebase.

the fast paced application development team (e.g. "We release a new version of Amarok every 6 weeks.")

hybrid SC-but-also-individual-releases-with-focus-on-specific-targets (e.g. "Marble is part of the KDE Edu module, but also is targetting smart phones in an agressive manner.")

fast paced development driven by external requirements (e.g. "KDE PIM is in practice primarily developed according to the needs and schedules of paying clients.")

tight knit community that co-maintains a set of components/applications (e.g. "All applications in KDE Games are worked on communally by whomever is currently active in the KDE Games team at the time.")

A team like this will most likely find that a single repo holding the entire module would be most convenient. This would make (for example) applying a fix or new caching model across all applications easier.

set of components that share local libraries and only make sense when released together (e.g. "kdebase-workspace hosts several local, non-BIC libraries shared between KDM, KWin, Plasma-* shells and contains all the base plugins required for a reasonably functioning KDE Workspace.")

downstream kde packagers

KDE bleeding edge users/testers

The situation here should be much the same as before. People using scripts like kdesvnbuild will be able to download and update kde as before. The scripts themselves however will need to be modified to address any new organisation.