From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marex@denx.de>
Date: Mon, 23 Jul 2012 04:13:45 +0200
Subject: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12
In-Reply-To: <CALButCKeTeWHbgspHM6=Wyw+7mXWvq6mJH8WxHyFLzVxbE2ByA@mail.gmail.com>
References: <m2wr2375rq.fsf@lamuella.denx.de>
	<201207230347.31993.marex@denx.de>
	<CALButCKeTeWHbgspHM6=Wyw+7mXWvq6mJH8WxHyFLzVxbE2ByA@mail.gmail.com>
Message-ID: <201207230413.46102.marex@denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Dear Graeme Russ,

> 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

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