[Gta04-owner] Status PCBs / Kernel development

NeilBrown neilb at suse.de
Fri Apr 1 10:44:50 CEST 2011


On Fri, 1 Apr 2011 09:31:34 +0200 "Dr. H. Nikolaus Schaller"
<hns at goldelico.com> wrote:

> 
> Am 31.03.2011 um 19:44 schrieb Peter Klassen:
> 
> > Hi all,
> > I've discovered an interesting link regarding this topic. This site
> > contains more links, maybe there is some useful info, if no experienced
> > developer will step out.
> > 
> > http://kernelnewbies.org/UpstreamMerge
> 
> This subpage gave me a lot of insights:
> 
> 	http://kernelnewbies.org/UpstreamMerge/SubmittingPatches
> 
> And questions what it means for our project...
> 
> The first one is for
> 
> > 9) Name your kernel version.
> > It is important to note, either in the subject line or in the patch
> > description, the kernel version to which this patch applies.
> > 
> > If the patch does not apply cleanly to the latest kernel version,
> > Linus will not apply it.
> > 
> 
> It is obvious why this must be, but the question arises how
> we maintain a tree that is up-to-date what Linus thinks the
> latest kernel version is.
> 
> My observation (from my work with drivers) is that it may take
> weeks from the moment where you download some kernel source,
> until a new driver is working good enough so that you consider
> submitting a patch.
> 
> In that time, several release candidates of a new kernel have appeared
> and that what Linus will think is the latest kernel version may have
> diverged from what your start was.
> 
> So what I do not understand yet is how we can update the base on
> which we work while we work. I.e. track/merge that what Linus is
> doing.
> 
> Well, this may introduce some incompatibilities to our own work
> because others also may change the basis, but that is ok.
> 
> As far as I understand, this has something to do with correctly
> setting up our git tree (copy) we work on. And, we regularily
> have to synchronize it with the mainline.
> 
> The other area is about
> 
> > 3) Separate your changes.
> 
> Here, I think we have to define some priority list what we
> want to get in first and what later on.
> 
> I think it should be sorted by descending priority. Priority
> being defined as some "usefulness to everyone".
> 
> That would IMHO be
> 1. board file (nowhere in kernel)
> 2. display driver (nowhere in kernel)
> 3. other drivers (some already available in kernel)
> 
> What I am not sure about is 1&2. They are logically
> separate, but useless if we don't have both combined.
> 
> So getting upstream one of them isn't enough.
> 
> 
> What are your experiences and suggestions?

I don't think that we should be sending separate patches up stream, but
rather should be asking Linus or someone to pull from a git tree.
Obviously the git tree will contain lots of patches, but we don't need to
send them separately.

I would have a number of "topic branches".  One for core gta04 things like
the board file, and one for each driver, whether a new driver or enhancements
to an existing one.

Then from time to time we merge all of the topic branches into a 'testing'
branch (or something like that) which we all use for testing the code on our
devices.

Also from time to time we update the 'origin' branch and 'pull' it into each
of the topic branches, resolving any conflicts.

When we feel a branch is ready for mainline, we ask someone to 'pull' it.  It
then gets into main line, comes back through our origin branch and we find
that the difference between that topic branch and origin becomes nothing.

Always update 'origin' and pull into a topic branch before sending a pull
request.  You can probably ask for the commit just before the merge to be
pulled so we don't get extra empty merges in mainline, but we need to make
sure a merge will succeed without conflicts before sending a pull request.

Where do I find the 'board' file in the current git tree?? and how does it
relate to the various 'mach-' and 'plat-' files??

NeilBrown



More information about the Gta04-owner mailing list