xsf-docs/reference/experimental.txt | 98 ++++++++++++++++++++++++++++++++++++ 1 file changed, 98 insertions(+)
New commits: commit a214fc59e4942e5dd69dead256dbb64217eaad28 Author: Cyril Brulebois <k...@debian.org> Date: Sun Apr 3 19:24:17 2011 +0200 experimental: More or less final tweaks. diff --git a/xsf-docs/reference/experimental.txt b/xsf-docs/reference/experimental.txt index 506e2ea..522ef3f 100644 --- a/xsf-docs/reference/experimental.txt +++ b/xsf-docs/reference/experimental.txt @@ -20,7 +20,7 @@ A quick overview of how things work upstream for the server: It doesn’t make much sense to try and package `master` on a continuous fashion, since the ABI can be broken multiple times, without a bump for the ABI version numbers every time. It’s usually done once a bunch -of majors changes landed, and when things are supposed to be stable +of major changes landed, and when things are supposed to be stable for a while. On the packaging side, as explained on the link:dependencies.html[dependencies between server and drivers] page, a bump means the need for a rebuild of the relevant drivers (input @@ -29,8 +29,8 @@ and/or video). That’s why the idea is to concentrate on upstream release candidates and official releases. Depending on available developer time (both upstream and in Debian), several branches can be developed/maintained -in parallel, so both `1.9` and `1.10` can be worth having at the same -time. +in parallel, so it can be worth having several versions available in +parallel, which is where `experimental` is handy. Keeping on with this example, with `1.9` in `unstable`, release candidates for `1.10` can be uploaded to `experimental`, along with a @@ -44,7 +44,8 @@ To avoid repetitive and sometimes pointless work, it’s probably a good idea to upload (to `experimental` as well) only a few drivers built against the server in `experimental`. ABI might be bumped between release candidates (that happened between `1.10rc3` and `1.10` for -example), so drivers would need to be rebuilt. +example), so drivers would need to be rebuilt (even though binNMUs +might help). The proposed drivers can be seen on the link:squeeze-backports.html[backports policy for squeeze] page, along @@ -54,7 +55,7 @@ with a tiny description for each. Building drivers in experimental -------------------------------- -Having a driver in experimental doesn’t change much: It is sufficient +Having a driver in `experimental` doesn’t change much: It is sufficient to declare a build-dependency against `xserver-xorg-dev (>= $serverminver)`, where `$serverminver` can be seen in: @@ -81,7 +82,7 @@ Instead, that seems more natural: * `1.42-1` to `unstable`. * `1.42-1+exp1` to `experimental`: bump the build-dep. - * `1.42-2` to `unstable`: add a bugfix to `unstable`’s version. + * `1.42-2` to `unstable`: add a bugfix to ++unstable++’s version. * `1.42-2+exp1` to `experimental`: rebuild against experimental (merging or rebasing the build-dep bump). commit 553f78a335650aadb9b79734ef85fb9e464a7574 Author: Cyril Brulebois <k...@debian.org> Date: Sun Apr 3 19:05:21 2011 +0200 experimental: Add a note about “double uploads”. diff --git a/xsf-docs/reference/experimental.txt b/xsf-docs/reference/experimental.txt index 99f513f..506e2ea 100644 --- a/xsf-docs/reference/experimental.txt +++ b/xsf-docs/reference/experimental.txt @@ -81,6 +81,17 @@ Instead, that seems more natural: * `1.42-1` to `unstable`. * `1.42-1+exp1` to `experimental`: bump the build-dep. - * `1.42-2` to `unstable`: add a bugfix. + * `1.42-2` to `unstable`: add a bugfix to `unstable`’s version. * `1.42-2+exp1` to `experimental`: rebuild against experimental (merging or rebasing the build-dep bump). + +**** +.Note + +Remember `experimental` is special. With the above sequence of +uploads, if the `1.42-2+exp1` version isn’t uploaded, the +`1.42-1+exp1` upload might disappear from `experimental` after some +time, since the version in `unstable` is more recent: the “obsolete” +package goes away. That’s why it’s important to remember uploading to +`experimental` as well when uploading a new driver to `unstable`. +**** commit be963b3947257dd9a7782c0eb204dd64901514d4 Author: Cyril Brulebois <k...@debian.org> Date: Sun Apr 3 18:55:49 2011 +0200 experimental: Mention selected drivers, and how to build. diff --git a/xsf-docs/reference/experimental.txt b/xsf-docs/reference/experimental.txt index 512bc38..99f513f 100644 --- a/xsf-docs/reference/experimental.txt +++ b/xsf-docs/reference/experimental.txt @@ -36,3 +36,51 @@ Keeping on with this example, with `1.9` in `unstable`, release candidates for `1.10` can be uploaded to `experimental`, along with a few drivers so that it’s actually useful. + +Selecting drivers +----------------- + +To avoid repetitive and sometimes pointless work, it’s probably a good +idea to upload (to `experimental` as well) only a few drivers built +against the server in `experimental`. ABI might be bumped between +release candidates (that happened between `1.10rc3` and `1.10` for +example), so drivers would need to be rebuilt. + +The proposed drivers can be seen on the +link:squeeze-backports.html[backports policy for squeeze] page, along +with a tiny description for each. + + +Building drivers in experimental +-------------------------------- + +Having a driver in experimental doesn’t change much: It is sufficient +to declare a build-dependency against `xserver-xorg-dev (>= +$serverminver)`, where `$serverminver` can be seen in: + + * `debian/serverminver` in the `xorg-server` source package: see its + first line. + * `/usr/share/xserver-xorg/inputdrvdep`: see the needed version of + `xserver-xorg-core`. + * `/usr/share/xserver-xorg/videodrvdep`: ditto. + +So, for a given version of a driver in `unstable`, bumping the +build-dep version and uploading to `experimental` should be enough, +providing it doesn’t require further changes (source code changes are +sometimes needed to support building against a newer server). When +that happens, the revision number can be constructed by appending +`+exp1`. The idea here is to avoid things like: + + * `1.42-1` to `unstable`. + * `1.42-2` to `experimental`: bump the build-dep. + * `1.42-3` to `unstable`: revert the build-dep bump, add a bugfix. + * `1.42-4` to `experimental`: build the build-dep again, keep the bugfix. + * etc. + +Instead, that seems more natural: + + * `1.42-1` to `unstable`. + * `1.42-1+exp1` to `experimental`: bump the build-dep. + * `1.42-2` to `unstable`: add a bugfix. + * `1.42-2+exp1` to `experimental`: rebuild against experimental + (merging or rebasing the build-dep bump). commit adbac8e5711754ab9de0270db89de9c6285b7e45 Author: Cyril Brulebois <k...@debian.org> Date: Sun Apr 3 05:20:35 2011 +0200 experimental: New documentation. Let's try and document the specific handling of sid+experimental packages for server+drivers. diff --git a/xsf-docs/reference/experimental.txt b/xsf-docs/reference/experimental.txt new file mode 100644 index 0000000..512bc38 --- /dev/null +++ b/xsf-docs/reference/experimental.txt @@ -0,0 +1,38 @@ +Handling multiple server versions thanks to experimental +======================================================== +Cyril Brulebois <k...@debian.org> + + +Context +------- + +A quick overview of how things work upstream for the server: + + * Patches get reviewed and merged into the `master` branch. + * After a few release candidates, `master` gets tagged (say: `1.10` + or `1.10.0`), and a stable branch (`server-1.10-branch` in this + case) is created to receive bug fixes. + * Those bug fixes usually are cherry-picks from commits in the + `master` branch. + * This leads to stable bugfix releases: `1.10.1`, `1.10.2`, and + so on. + +It doesn’t make much sense to try and package `master` on a continuous +fashion, since the ABI can be broken multiple times, without a bump +for the ABI version numbers every time. It’s usually done once a bunch +of majors changes landed, and when things are supposed to be stable +for a while. On the packaging side, as explained on the +link:dependencies.html[dependencies between server and drivers] page, +a bump means the need for a rebuild of the relevant drivers (input +and/or video). + +That’s why the idea is to concentrate on upstream release candidates +and official releases. Depending on available developer time (both +upstream and in Debian), several branches can be developed/maintained +in parallel, so both `1.9` and `1.10` can be worth having at the same +time. + +Keeping on with this example, with `1.9` in `unstable`, release +candidates for `1.10` can be uploaded to `experimental`, along with a +few drivers so that it’s actually useful. + -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1q6r3y-00056m...@alioth.debian.org