Hi Marek,
On Mon, Jul 23, 2012 at 11:47 AM, Marek Vasut marex@denx.de wrote:
Dear Graeme Russ,
Yes - But see above. If the build infrastructure is building with all the repos applied we will get instant feedback that a repo is out-of-step with mainline rather than waiting for Wolfgang to pull.
Uh, I think my english decoder got clogged somewhere in here ... can you ignore/abort/retry please ? ;-)
Sometimes after Wolfgang pulls a repo (or applies patches directly to mainline) a subsequent pull of another repo will have a merge conflict. It would be nice to catch them early
<random thoughts> What I am thinking is a patch tracker (not manager) which basically has an internal queue of unapplied (to mainline) patches. When a patch gets submitted, it will be sanity checked (checkpatch). If the sanity checks pass (or are overruled) then a git-apply test is run. If this passes, the patch gets added to the queue. The mailing list gets informed that the patch has been 'provisionally accepted' and has been queued for formal review.
If a patch get's NACK'd, or the auto-build infrastructure determines that the patch breaks the build, the patch gets removed from the queue. When a patch gets removed from the mailing list gets informed that the patch has been removed from the queue and a new revision needs to be resubmitted.
If a new revision of a patch is submitted, the patch tracker attempts to replace the old patch at the same location. If the new patch cannot be applied, it (and the old patch) gets removed from the queue
I'm thinking that the patch tracker can keep track of which repo the patch belongs to. If the patch tracker had a non-mailing list interface that triggered the patch tracker to apply the patch to the corresponding repo, that would be great.
So any time a patch is committed to mainline or a repo, the patch tracker would remove that patch from the queue then redo the git-apply test to each patch left in the queue. </random thoughts>
Regards,
Graeme