Dear Graeme Russ, > Hi Marek, > > On Mon, Jul 23, 2012 at 11:47 AM, Marek Vasut <ma...@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
Oh, that's true > <random thoughts> Ok, this tag prooved to be very dangerous in the past when produced by you ;-D > 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. Mm mm, nice :) > 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 Here is the point where you'll need the deus-ex-machine to intervene ... since some patches can't be automatically processed so easily. > 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. Certainly. > 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> Wowzie, I survived the section this time :-) But then, how shall we go about it? Any python gurus around? > Regards, > > Graeme [...] Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
