2011/10/7 Marc-André Laverdière <marc-andre@atc.tcs.com>:
Wow, I really missed the 'big debate' :)
[...]
- 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.
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 ?
However, that is not so great
if we 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
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.
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?
That is call 'your local directory'
[snipped section essentially describing 'gerrit' workflow. we are
working on that... ]
- I don't think we can expect developers to run a build before each
push,
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'
This would massively slow them down IMHO.
Well that would massively speed up everybody else.
We have a relatively high rate
of commits.
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.
It does happen from time to time that a commits comes in
just after you do your ./g pull -r ; make.
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
So you have to repeat the process, and that isn't so nice.
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'
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.
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).
http://tinderbox.libreoffice.org/MASTER/status.html
Norbert
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice