[cmake-developers] Adding argument "OPTIONAL" to find_package() and add_subdirectory

[Brad King]

On 06/23/2011 10:36 AM, Michael Wild wrote:
> On 06/23/2011 04:11 PM, Brad King wrote:
>> We manually select topics from 'next' and merge them to 'master'.
>> Only topics in master will be released.
> 
> So, how does that work? Do you look for the merges in 'next' that you
> like, and then re-merge them to 'master' directly from the topic-branch?

Yes.  The complete workflow is described generically here:

  http://public.kitware.com/Wiki/Git/Workflow/Topic

We use a "topic stage" repository to keep explicit topic branch heads
that are not in all integration branches:

  http://public.kitware.com/Wiki/Git/Workflow/Stage

CMake's topic stage is published here:

  http://cmake.org/stage/cmake.git

The set of branches changes regularly as topics are added or finished.

> Something like this?
> 
> -- A ------------------------ I -- master
>     \   \   \                /
>      \   \   C --- D ------ G -- topic2
>       \   \                  \
>        \   B -- D -- topic1   \
>         \        \             \
>          \------- F ------------H -- next

Yes, exactly.

> i.e. everything starts at A, 'master' and 'next' being identical. Then,
> someone creates 'topic1' and merges it into 'next' (commit F).
> Meanwhile, another topic, 'topic2' is created, and also merged into
> 'next' (commit H). Now, 'topic1' just isn't ready, but 'topic2' is, so
> it gets merged into 'master' (commmit I). Is this correct?

Yes.  It gets a little more complicated when there are conflicts:

  http://public.kitware.com/Wiki/Git/Workflow/Topic/Conflicts

> Is 'next' kind of your "throw-away" integration branch?

Yes.  No topics are allowed to see any of the merges into next.  There
is even a check on the server that disallows topics (or master) to see
the beginning of next.

> Do you rebase it regularly onto master?

So far we haven't rewritten it but the workflow allows that because
nothing should be based on it.  Currently we have to avoid rewriting
the branch because some dashboard clients may do just "git pull" to
update.  Recent CTest versions do a fetch & reset so that they can
handle upstream rewrites.

I designed all of the above after reading about Git's own workflow:

  http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/howto/maintain-git.txt;hb=v1.7.5

Our "topic stage" takes the place of the maintainer's private repository.
I designed it to help distribute some of the maintainer's workload among
developers (and they don't even have to know; it's just part of their
workflow).

-Brad