Improving Our Docs

Jeff Spaleta jspaleta at
Fri Jun 21 17:20:13 UTC 2013


For starters to smoke test Mir I need:
The... canonical...set of branches for Mir and its dependencies as
used in current Mir development workflow necessary to smoke test a
binary mir in a locally controlled clean build environment
(/usr/local) so that I can use environment variables to switch from
the environment provided dependencies to the mir specific dependencies
if the environment does not provide them.  Current build from source
and test implicitly assumes you are going to pull patched deps from
ppa staging which implicitly assumes a very specific environment thus
a non-starter for anyone not using that environment.

If upstream stock releases of dependencies will suffice, the minimum
release number for that dependancy is fine (and this is generally
cullable from the debian packaging when general assumption is you are
not relying on vendor patches in that dependency and the stock version
is meant to be sufficient..caveats apply of course).

When its known that testability requires significant downstream
patchsets be applied to a stock upstream release or development tip,
then the bzr/git branch that matches that on-going development of that
patched dependency should be provided in the build from source
instructions instead of an upstream release number for that dep. So as
of now I understand that to mean the Mir lp trunk branch and ROAF's
mesa and xserver branches with mir specific changes should be included
as part of the build from source instructions .  In the future I
expect that the mesa/xserver branch urls can be replaced with upstream
development branch urls once necessary patches are upstreamed.

Based on my current understanding of the codebase, I think should be
able to get a clean build/testable build of mir from sources on a
CentOS 5.x or Debian stable system or for that matter any active U
LTS, if the necessary deps versions/branches are documented, all
without replacing any system packages and destabilizing the running
system. I guess I'll find out if that's true soon enough.

Beyond local build from source...
To have any hope of actually getting this packaged officially in
Fedora (and I daresay other distributions such as Debian), there must
be a way forward that does not require distribution level patching of
Mir's depchain, so upstreaming the Mir enabling patches for codebases
outside of Mir itself is somewhat important in the medium term.  But
before we burn that particular bridge, I have to be able to at least
smoke test Mir in a clean environment of my choosing.


On Fri, Jun 21, 2013 at 1:27 AM, Daniel Holbach
<daniel.holbach at> wrote:
> Hello,
> On 21.06.2013 00:55, Jono Bacon wrote:
>>  * How to write a a Mir backend for a window manager / toolkit. This
>> could really help other projects that are interested in supporting Mir.
>>  * How to build Mir for non-Ubuntu systems. Jef Spaleta shared this
>> concern with me this week, and I think some more generic build
>> instructions would be useful.
> In Alan asks if the pieces
> of text under "Building and installing from source" linked from
> aren't good enough yet.
> CCing Jef, maybe you could give some feedback on this thread or on the
> bug report mentioned above?
> Maybe the "Building and installing from source" docs are good enough and
> we just need to refer to them from
>>  * How to write a driver that supports Mir. This could be of interest
>> for a hardware company who is interested in exploring Mir support for
>> their hardware.
>> I have Daniel to take care of working with our community and Mir
>> engineers to put together these docs. Is anyone willing to help
>> contribute to putting this content together as part of this effort?
> I just filed these bugs to keep track of the docs related improvements:
> Have a great day,
>  Daniel
> --
> Get involved in Ubuntu development!
> Stay up to date: follow @ubuntudev on

More information about the Mir-devel mailing list