Projects/MoveToGit/Layout: Difference between revisions

    From KDE TechBase
    No edit summary
     
    Line 92: Line 92:
    * 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.")
    * 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.")
    * 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.")
    * 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
    * downstream kde packagers

    Latest revision as of 11:14, 18 September 2010

    Definitions

    modules:

    • each SC module is one repository except kdepim, it will be split into kdepim and kdepim-runtime.
    • each extragear application is one repository.
    • kdereview and playground are implemented with individual repos and/or branches?
    • tarballs stay the same as it is now

    split:

    • each SC application is one repository.
    • kdelibs, and kdepimlibs are one repo each kdepim will be split into kdepim and kdepim-runtime. kdebase can be split on workspace/runtime/apps, where optionally apps could be split further
    • extragear and review/playground as above.
    • tarballs stay the same as it is now

    Comparison

    Pros for each option (cons are rephrased as a pro for the other one) Note: no mention of the magnitude of each point has been made yet.

    svn2git

    modules:

    • some work has already been done on creating module repos
    • moves within modules can be ignored

    split:

    • existing rules can be used with minor changes for "self contained" applications

    Reviewboard

    modules:

    • less projects to choose from when submitting a patch? [web only, not an issue with post-review]
    • no namespacing issue

    split:

    • if something moves to another module, no changes are needed
    • ability to autocreate (and possibly assign) a review group per app, instead of per module

    comments:

    • the reviewer groups won't be affected

    Redmine

    modules:

    • no namespacing issue

    split:

    • source code links are automatically available on each applicaton page, instead of the module page

    gitolite

    modules:

    • no namespacing issue

    split:

    • easier to find projects (git.kde.org/APPNAME.git instead of git.kde.org/SOMEMODULE.git)

    git

    modules:

    • projects can keep their interdependencies, module-wide libraries and so on
    • less server space

    split:

    • moving a project (eg. to unmaintained) moves its whole history

    user workflow

    modules:

    • keeps a sense of community by having a whole module kept together
    • increases passive testing of trunk (more people to notice if the build's broken)
    • lower barrier to hacking on other projects in the module
    • easier to refactor a module [rare]
    • less downloading & disk space for those who want entire modules

    split:

    • less downloading & disk space for people who only want a small part of a module
    • easier to get started on one little app?
    • easier to avoid being exposed to unstable versions of other projects [I think that's a bit selfish though]

    comments:

    • kdesrc-build, build-tool and mr make it easy to handle large numbers of repos, although there's still room for improvement on userfriendliness.

    releases

    modules:

    • closer to what we have with svn??

    split:

    Social Workflows

    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.

    • Broad cross-module committers (e.g. dfaure and laurent)