[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

pkg-gnome SVN layout


 I would like to switch the SVN repository to a new layout.

 The most important change I I would like to do is to introduce a trunk/
 branch.  Its role would be to centralize all packaging fixes and track
 the newest packaged upstream release.

 While we're at it, it's a good occasion to revisit some other things:
 - usage of tags/, and perhaps even a real branches/ dir
 - package splitting criteria

 Currently the structure is as follows:
    |-- desktop
    |   |-- experimental
    |   |-- sarge
    |   `-- unstable
    |-- packages
    |   |-- experimental
    |   |-- sarge
    |   `-- unstable
    |-- tools
    |   |-- debian-comparator
    |   |-- gnome-pkg-tools
    |   `-- pbuilder
    `-- www

 (I think www, not being a package, doesn't need any change.)

 I see two reasons to have a trunk:
 - we currently have no defined merge process, so we commit some changes
   in unstable and other changes in experimental; we then have to guess
   how to merge the branches together: merge from unstable to
   experimental, or the other way around, or both ways...  This is
   suboptimal and risky.
 - we have no place to prepare the latest upstream development releases,
   experimental only allows for one more GNOME series which is
   currently GNOME 2.16

 Hence, I propose we switch to a layout with a trunk/ along the
 branches, it could look like:
    |-- experimental
    |-- sarge
    |-- trunk
    `-- unstable

 Using tags/ could be a nice addition as we currently don't have an easy
 way to retrieve the debian/ of a package.  I understand it adds a
 burden; I'm fine with or without, please voice your preference.
   It's also classical to have a branches/ dir, so we could switch to
 a more traditional structure like:
    |-- branches
    |   |-- experimental
    |   |-- sarge
    |   `-- unstable
    |-- tags
    `-- trunk

 My personal preference goes to not having a "branches/" dir.

 Finally, there is the question of the package types that we host under
 pkg-gnome.  I think there are mainly three types:
 - GNOME official packages
 - random GNOME-ish officious packages (either from gnome.org or from
   other sources)
 - Debian packaging specific packages

 I personally find the difference important, but I don't need to have
 them split in various dirs.  So, we could either:
 - use a flat structure, let's call it layout 1:
    |-- devhelp
    |-- gksu
    |-- glib2.0
    |-- gnome-pkg-tools
    |-- nautilus
    |-- pessulus
    |-- pygtk
    `-- rhythmbox

 - use the current official/unofficial/debian split, layout 2:
    |-- extra
    |   |-- gksu
    |   `-- rhythmbox
    |-- official
    |   |-- devhelp
    |   |-- glib2.0
    |   |-- nautilus
    |   |-- pessulus
    |   `-- pygtk
    `-- debian-specific
        `-- gnome-pkg-tools

 - split even more by GNOME sections, layout 3:
    |-- admin
    |   `-- pessulus
    |-- bindings
    |   `-- python
    |       `-- pygtk
    |-- debian-specific
    |   `-- gnome-pkg-tools
    |-- desktop
    |   `-- nautilus
    |-- devtools
    |   `-- devhelp
    |-- extra
    |   |-- gksu
    |   `-- rhythmbox
    `-- platform
        `-- glib2.0

 My personal preference goes to a layout similar to the current one (2),
 or a flat layout (1) as I think modules move between sections, or gain
 / lose official status, and also to make merge URLs a bit simpler to

 So, I would like to hear:
 - what other people think of the addition of the trunk
 - whether we should use tags and perhaps even branches
 - which package splitting criteria we should use

 (There might some details to discuss afterwards, such as whether to
 have branches at the top-level, or per-package, or per-package type.)

Loïc Minier <lool@dooz.org>

Reply to: