xorg: Changes to 'xsf-docs'
xsf-docs/reference/experimental.txt | 98 ++++++++++++++++++++++++++++++++++++
1 file changed, 98 insertions(+)
New commits:
commit a214fc59e4942e5dd69dead256dbb64217eaad28
Author: Cyril Brulebois <kibi@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 <kibi@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 <kibi@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 <kibi@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 <kibi@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.
+
Reply to: