<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    Following on to this, I suggest that it should not be hard to
    configure a Windows machine with 16G of RAM, and set aside most of
    that memory as a RAM-drive. Then run the Windows build on the
    RAM-drive. That should speed things up.<br>
    I do that here for some of my builds, and it makes a massive
    difference.<br>
    <br>
    In fact, I could probably get permission to host such a machine here
    at work, provided that the build slave does not soak up too much
    network bandwidth (I'm in South Africa, bandwidth is expensive).<br>
    <br>
    Regards, Noel Grandin<br>
    <br>
    Noel Grandin wrote:
    <blockquote cite="mid:4E8F07C2.3090702@peralex.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <font face="Tahoma">It seems like Windows builds in particular
        would benefit from either (a) tons and tons of RAM or (b) an
        SSD.<br>
        Who owns the hardware? Perhaps I (or the company I work for) can
        contribute to the cost of (a) or (b).<br>
        <br>
        Regards, Noel Grandin<br>
      </font><br>
      Norbert Thiebaud wrote:
      <blockquote
cite="mid:CAFWMYEE1_qTyxF4ennp1sxy913cNNQD-QQksWmLvSJ=NttTqTA@mail.gmail.com"
        type="cite">
        <pre wrap="">2011/10/7 Marc-Andr&eacute; Laverdi&egrave;re <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:marc-andre@atc.tcs.com">&lt;marc-andre@atc.tcs.com&gt;</a>:
</pre>
        <blockquote type="cite">
          <pre wrap="">Wow, I really missed the 'big debate' :)
</pre>
        </blockquote>
        <pre wrap="">[...]
</pre>
        <blockquote type="cite">
          <pre wrap="">- I agree that an email to 200 people is not super interesting. I think
we should run git bisect to try building for every commit until we hit
one that breaks, or build on each commit.
</pre>
        </blockquote>
        <pre wrap="">On linux and Mac we build fast enough that this is not a problem.
the reason we get to 200 people, is that one commit break things, and
200 distinct people commit on top of that,
there is no way for a tinderboxes to decided who to send emails to.
you can't just send it to the original aithor because you can (and do)
get the seuqnce

A push commit 1 that break
B push commit 2 that break
A push fix to the commit 1 breakage

In that case how do you make a tinderbox realize that it should send
an email to B only ?

</pre>
        <blockquote type="cite">
          <pre wrap="">However, that is not so great
if we &nbsp;have commits for which the thing is fixed in the next commit. I
am not expecting everyone to be comfortable with git rebase to the point
</pre>
        </blockquote>
        <pre wrap="">I am expecting them to be, that comes with the responsibility of being
a committer, and I do think that keeping the history bisectable is a
very good and important thing.

</pre>
        <blockquote type="cite">
          <pre wrap="">of merging commits all the time. But if we put such a policy in place,
it would help people learn very very fast :)
- Can we have some intermediary branch then? Or some 'proofed' branch?
</pre>
        </blockquote>
        <pre wrap="">That is call 'your local directory'

[snipped section essentially describing 'gerrit' workflow. we are
working on that... ]

</pre>
        <blockquote type="cite">
          <pre wrap="">- I don't think we can expect developers to run a build before each
push,
</pre>
        </blockquote>
        <pre wrap="">Yes we absolutely can expect that. it is actually a bare minimum !!!!!
pushing to the main repo is not a game of 'throw mud at the wall and
see what stick'

</pre>
        <blockquote type="cite">
          <pre wrap="">This would massively slow them down IMHO.
</pre>
        </blockquote>
        <pre wrap="">Well that would massively speed up everybody else.

</pre>
        <blockquote type="cite">
          <pre wrap="">We have a relatively high rate
of commits.
</pre>
        </blockquote>
        <pre wrap="">about 50 a day, and that is not 50 distinct push

the tinderboxes do 20 to 30 iteration a day
that is very close to an iteration per push.

</pre>
        <blockquote type="cite">
          <pre wrap="">It does happen from time to time that a commits comes in
just after you do your ./g pull -r ; make.
</pre>
        </blockquote>
        <pre wrap="">So ? the issue is very rarely a conflict. the issue is new code not building.
So if you successfully did a make before git pull -r, that cover 95%+
of the breakages

</pre>
        <blockquote type="cite">
          <pre wrap="">So you have to repeat the process, and that isn't so nice.
</pre>
        </blockquote>
        <pre wrap="">Breaking master is not nice for the others.. because now they can
really check that thei change are ok, sometime they can't even get
to compile their change at all because to build can't even get there,
so they have to bring locally master back to a 'older good point'
(which require _them_ to 'repeat the proces'


</pre>
        <blockquote type="cite">
          <pre wrap="">Now, if I have to build something a gazillion times slower before I can
push, will I _ever_ be able to push? I'm not asking rhetorically by the way.
</pre>
        </blockquote>
        <pre wrap="">Then don't push every 5 minutes.
you only need make clean; make after a pull.
so pull -r. make clean; make
now you have a tree you can wok in. (provided master has not been
broken... see how that brokenness is contagious ?)
code, make, fix, make, fix, make.. commit, git status (to veryfy that
you did not miss anything in the commit, if necessary:git commit
--amend)

Note that the 'make' above do not have to be global make... except for
a last one when you ar ready to pull -r, you can make the module you
changed (if it is a old-dmake module you need to build and deliver)

Then pull -r
if you have conflict resolve them and definitely make
if you have no conflict, eyeball the change that got in and make a
call about the likelihood of a 'silent' conflict.

At that point, if you want to be very safe: make clean/autogen/make
again... but if you don't an push, you still will be very unlikely to
have broken master.

Push ... AND keep an eye on the tinderboxes. usually within 20 minutes
you should have the result of a tinderbox run with your pushed change
in it (except windows so far).

<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://tinderbox.libreoffice.org/MASTER/status.html">http://tinderbox.libreoffice.org/MASTER/status.html</a>

Norbert
_______________________________________________
LibreOffice mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:LibreOffice@lists.freedesktop.org">LibreOffice@lists.freedesktop.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/libreoffice">http://lists.freedesktop.org/mailman/listinfo/libreoffice</a>

</pre>
      </blockquote>
    </blockquote>
    <br>
  </body>
</html>