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

[Michael Wild]

On 06/23/2011 06:02 PM, Brad King wrote:
> 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

Thanks for the thorough explanation. I have to say, it is very well
thought-through, I'll try to enforce something similar for my projects.
gitworkflows(7) always seemed a bit unwieldy to me, but then it is also
geared towards much larger projects with many more contributors...

Michael