[RFC] In-tree documentation of driver deviations for Lucid and Maverick

[Brad Figg]

On 11/23/2010 06:16 AM, Stefan Bader wrote:
> As discussed on UDS, we want to document driver deviations in a file, to make
> automated checks possible and to have the documentation even simpler to find.
>
> May proposal would be a file called debian.master/deviations.txt (which would
> allow to add additional debian.*/deviations.txt for topic branches).
>
> The contents are similar to the MAINTAINERS file. Attached are the prepared
> files for Lucid and Maverick.
>
> Comments? Objections? Modifications? Agreement?
>
> -Stefan
>

Looks good. I do have one thing to consider. If you're going to use this as the
input for scripts, I'd suggest using json data format. This is easy to read text
and the best part is it easily loads into python as a dictionary or list or whatever
you want. Also it means that the name/value pairs can be readable strings instead
of single letter abbreviations. I use this format all the time now and have
convinced others to use it as well.

Two entries would look something like:

{
     "drm subsystem" : {
         "mailing list" : "kernel-team at lists.ubuntu.com",
         "repo"         : "git://git.kernel.org/pub/scm/linux/kernel/git/smb/linux-2.6.32.y-drm33.z.git",
         "files"        : [
             "drivers/gpu/drm/*",
             "include/drm/*"
         ],
         "comments"     : "Graphics bugs were claimed to be not fixable in 2.6.32. All upstream
     	                  had moved to 2.6.33 and abandoned 2.6.32.
	                  The combined 2.6.32.y/DRM33.z tree is maintained as an upstream source
	                  for Ubuntu and Debian."
     },

     "sfc driver" : {
         "mailing list" : "kernel-team at lists.ubuntu.com",
         "repo"         : "git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.33.y.git",
         "files"        : ["drivers/net/sfc/*"],
         "comments"     : "Was requested in order to support newer servers and driver had changed
	                  beyond a point to SRU it later.
                          "
     }

}

-- 
Brad Figg brad.figg at canonical.com http://www.canonical.com