[LLVMdev] Develop on trunk.

[Mikael Lyngvig]

Guys, that was very interesting and useful stuff you preached there.  Mind
if I make a patch to the FAQ and include it somewhere?

"Q: When should I develop against a branch?  A: Only if you are making
really big or controversial changes.  ... blah blah

I am thinking that it would be highly useful for the project, if somebody
(yours sincerely) took it upon himself to hunt and gather the very
interesting bits that often pop up in these mailing lists.  As a newbie, I
think the lists are very valuable, but you cannot expect people to always
read all of the old stuff on the lists and as much as we all love Google's
search engine (bing! bing!), it does always find the stuff you want to find
(nearly, but not always).


Cheers,
Mikael
-- Love Thy Frog!

2012/6/13 Chandler Carruth <chandlerc at google.com>

> On Wed, Jun 13, 2012 at 11:43 AM, Andrew Trick <atrick at apple.com> wrote:
>
>>
>> On Jun 13, 2012, at 7:15 AM, Sergei Larin <slarin at codeaurora.org> wrote:
>>
>> Again, this is branch code, but if I can see something wrong in platform
>> independent portion, I'll track it on the trunk.
>>
>>
>> I hate to be the one to start this thread, but I have to say it at least
>> once...
>>
>> General advice. Working off trunk will be less painful than
>> cherry-picking.
>>
>
> TL;DR: Here here. Yes, more, please!
>
> <soap box>
> I'll go further: don't use development branches. It's just not worth it.
>
> I say this as someone who created a development branch of Clang. It was
> and is a pile of pain. We want to kill it with fire.
>
> A lot of people think that a development branch is a useful way to solve
> problems they run into while developing on trunk:
> - Commit velocity
> - Code review latency
> - API instability
> - Rough or WIP code being seen by others
>
> I assert that these are either not actual problems when working on trunk,
> or are problems that will actually be worse with a development branch. They
> are very bad reasons to form one.
> - Commit velocity may go up, but testing, correctness, and quality of
> those commits will go down. You also have the added burden of having to
> commit merges.
> - Code review latency doesn't go away, it gets deferred until the time at
> which you want to re-integrate your changes. Deferring code review is like
> deferring payments on a loan. The more you do it, and the longer you do it,
> the more interest you build up. It's especially like a loan in that it is a
> *compounding* phenomenon. However, it's worse than most loans, because the
> interest rate is somewhere between 20% and 2000%. In such scenarios,
> micro-payments start to make sense, in the same way that tiny incremental
> patches make sense on trunk.
> - API instability is the exact same problem as code review latency -- the
> API is no more stable, you're just deferring work. The interest rate here
> is much lower at least, but there is a secondary gotcha -- if your code is
> on trunk, then the API *changer* will do much of the work for you.
> - Rough / WIP code *should* be seen by others, in order to get early
> feedback, avoid bad paths of implementation etc. We should indoctrinate
> ourselves as developers with a delightful glee in showing code before it's
> 100% ready for prime time.
>
>
> There are actual cases where you must use a development branch, such as
> due to controversial changes that need to be demonstrated as viable before
> accepted, or drastic internal changes that require a lot of work to get
> into a working state (the type-system rewrite of LLVM is a good example
> here).
>
> If you find yourself in such a scenario, it is essential to make the
> development branch look as much like trunk as possible. Integrate daily at
> least, and multiple times a day if you can. Otherwise, all of the problems
> above will eat away at your productivity.
>
> </soap box>
>
> -Chandler
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120614/fbb13dbd/attachment.html>