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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120613/4c6ada4b/attachment.html>
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>
On Wed, Jun 13, 2012 at 3:41 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote:> 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). >Yes, patches to the FAQ are very welcome. We should honestly organize the FAQ a bit differently if you want to start really working to flesh it out with more useful information. I think there should be three FAQs at least: 1) A FAQ for the LLVM Project, which is applicable to LLVM, Clang, and often other subprojects. This would include the license section in the current LLVM faq, and maybe some other points. 2) A FAQ for the LLVM codebase -- specific to the code, libraries, and infrastructure in the primary project. 3) A Clang FAQ for the FE-specific stuff. The current FAQ is mostly #2, with a bit of #1, and a lot of out-of-date or flat out wrong information. The current FAQ could probably stay as one page, or be two pages, but it should have a clear and well deliniated split between #1 and #2. We should discuss creating #3 on cfe-dev in a separate thread if you're interested. If you're proposing patches, here are some suggestions as the standard process may not work as well... which others may contradict if they disagree... ;] - Patches to fix the formatting / structure should go directly to llvm-commits - Patches to add a FAQ entry to section #1 above should at least go to llvm-commits, llvmdev, and possibly a few of the mailing lists for suprojects to get wider feedback. - Patches to add a FAQ entry to section #2 above should go to llvm-commits and llvmdev. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120613/ec5a721b/attachment.html>
Chandler Carruth <chandlerc at google.com> writes:> - 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.None of those things need go down. We have our own testing regime.> - Code review latency doesn't go away, it gets deferred until the time > at which you want to re-integrate your changes.> - API instability is the exact same problem as code review latency -- > the API is no more stable, you're just deferring work.Yes, none of these things go away. That's not the point. The point is that with a separate branch one can *schedule* them. Code review on llvm-commits is painful not because of the actual reviews but because it takes so dang long to get one. We can't wait a week or more to be able to use our own code.> - 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.I'd LOVE to do this. It doesn't happen early, no matter when I send it. It always happens 2-3 weeks later. -Dave
<dag at cray.com> writes:>> - API instability is the exact same problem as code review latency -- >> the API is no more stable, you're just deferring work. > > Yes, none of these things go away. That's not the point. The point is > that with a separate branch one can *schedule* them. Code review on > llvm-commits is painful not because of the actual reviews but because it > takes so dang long to get one. We can't wait a week or more to be able > to use our own code.Actually, git would solve a lot of these problems. With git we could share code within our organization while it is being reviewed upstream. I am working very hard to get git adopted here but it will take some time. Still, I think that is an important step to allow 3rd parties to develop on trunk and still maintain the development speed they require. It would be easier if LLVM also adopted git but I don't think that's going to happen, unfortunately. -Dave