Hi,
On Tue, Apr 23, 2013 at 03:36:51PM +0200, Noel Grandin wrote:
On 2013-04-23 15:29, Stephan Bergmann wrote:
On 04/23/2013 03:09 PM, Bjoern Michaelsen wrote:
Why are you rebasing daily? I work on patches and rebase them
once directly
before pushing them to master sparing myself a lot of pain (and severely
reducing the risk of ending up with rebasing on a broken master
etc.). I can see others doing the same.
An alternative model is to "pull often, push often."
Also called the using-git-like-SVN-method. ;)
Noel is right though, that frequent pulls might be prohibitive depending on
your hardware.
I think the frequency of iteration (daily, weekly) is not really that
important. Do as fast as you comfortably can with your hardware.
The important key point IMHO is not to pull more that you push, otherwise you
degrade yourself to a very expansive tinderbox.
I rebase once a week because my changes have a high likelihood of
triggering conflicts.
That sounds sensible to me. What I do is, I have a cronjob that runs a master
build and populates my ccache to the newest master, so when I rebase I
essentially just copy in the files from cache (and I only rebase on a master
that finished building).
And I "push seldom" to reduce the reviewing workload on Stephan :-)
How about pushing to gerrit and having a testbuild there? We are ressource
contrained still, but that bot surely is cheaper than Stephan ;)
Best,
Bjoern
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.