Hi Stefan,
On 07/17/2012 08:37 PM, Stefan Roese wrote:
On Tuesday 17 July 2012 01:11:01 Graeme Russ wrote:
It was discussed whether to do some "automatic" merging of these per-custodian trees into a central next, but majority of people believed that the patch handling process should remain as unchanged as possible in sync with the "principle of least surprise".
I agree that automatic merging is a 'Bad Thing(tm)'. But one thing I notice (and I don't know if this is a recent thing) but there seems to be a case of zero merge activity up to the closing of the merge window and then a rash of merging just prior to the RCs. I favour a more continuous merge strategy.
I favored the automatic merging at the conference mainly because of one reason:
To detect potential merge conflicts as early as possible. And send the result of this automated merge to the list (or a new list).
100% agree with first sentence. Worried about how much extra traffic an auto-build would cause if it was mailing the list as well
In combination with (automated) nightly builds this not only catches merge conflicts but also build problems. All this should be pretty easy to automate. And it moves the detection of those problems closer to the submission of the patches. So we (and the original patch authors) don't have to figure out what the patch was all about weeks later.
I think U-Boot has reached the point that purely manual patch management is not longer cutting the mustard.
Maybe it's time to seriously look at a gerrit + jenkins based solution?
Regards,
Graeme