[GIT PULL] at91: devices and boards files update for 3.3

[Guennadi Liakhovetski]

On Sat, 17 Dec 2011, Olof Johansson wrote:

> Hi,
> 
> On Sat, Dec 17, 2011 at 10:34 AM, Guennadi Liakhovetski
> <g.liakhovetski at gmx.de> wrote:
> > Hi Olof
> >
> > On Fri, 16 Dec 2011, Olof Johansson wrote:
> >
> >> Hi Nicolas,
> >>
> >> On Fri, Dec 16, 2011 at 8:37 AM, Nicolas Ferre <nicolas.ferre at atmel.com> wrote:
> >>
> >> > Yes, this ISI driver addition is also dependent on an update of the ISI
> >> > driver itself that will certainly be included in 3.3 by Guennadi using
> >> > v4L2 path.
> >> >
> >> > So, do we have to wait for its inclusion in linux-next or maybe we can
> >> > manage this little out-of-sync situation during the 3.3 life cycle...
> >> >
> >> > ISI is a "several times reworked" and "long-awaited" driver and I really
> >> > would like to see it included in mainline soon...
> >>
> >> I don't see why code that is known to be broken should be added to the kernel.
> >>
> >> The way these things are normally handled is that once Guennadi has
> >> the patch on a stable branch, we can add that branch as a dependency
> >> that your code requires. So we pull that in as a dependency and apply
> >> your code on top of it (or, if it is just one or two patches, that
> >> they are are cherry-picked into your branch in the same way).
> >>
> >> But that requires that he picks up the v4l patches and keeps it in a
> >> stable, small, branch and that said branch gets merged in the 3.3
> >> merge window before the branch containing these at91 changes do.
> >>
> >> Guennadi, sound reasonable to you?
> >
> > I'm not sure what you call a "stable" branch. If you mean a branch in some
> > tree somewhere (like my tree on linuxtv.org) then I wouldn't yet use that.
> > I think, there are two ways to handle this:
> 
> When I say "stable" branch, I mean a topic branch that is staged for
> 3.3, pulled into a for-next branch that is picked up by linux-next and
> that *will not be rebased* before the merge window. In other words,
> patches that have been staged and won't be touched before they go in.

Yeah, but it's only the actual Linus' tree, that is really stable, you 
know;-)

> It would them match case (2) below, but it would also allow us to
> merge in either a branch pull of said stable staging branch as a base
> for the at91 patch -- if the V4L code is merged before the at91 branch
> then git will handle it nicely.
> 
> > 1. Safe from the dependency and synchronisation PoV, but might cause
> > problems during merge. One of the patches gets an ack from the respective
> > maintainer but gets merged together with the other patch via the "wrong"
> > tree. E.g., someone from at91 could ack this patch and I could apply it to
> > V4L together with the actual ISI patch.
> >
> > 2. Each patch goes via its own tree, but we make sure, that at91 tree is
> > pushed to Linus after the V4L tree. This is more "correct" - each patch is
> > merged via its respective tree, but if the V4L tree is merged near the end
> > of the merge interval, it might be difficult for at91 to hit the remaining
> > window.
> >
> > I'm ok with either of the above.
> 
> Since we're trying to keep the amount of board code addition to a
> minimum on ARM right now, I would prefer if all changes to said code
> goes through arm-soc mostly to keep an eye on just what goes in, which
> means (2).

That's exactly why I said "with an ack" - I certainly wouldn't take a 
patch for outside of v4l without suitable acks.

> Do you normally get the v4l tree merged very late during
> the merge window?

IIRC, normally Mauro is trying to push v4l twice per merge window, so, it 
would be my task then to manage it in the first pull request.

> We can keep one late-merge branch in arm-soc that contain patches with
> external and possibly late dependencies and submit that branch last,
> but it would be good if we had a bit of margin to get it in. :)

Ok, let's try this.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/