mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Charles Manning <manningc2@actrix.gen.nz>
To: Greg KH <greg@kroah.com>
Cc: cdhmanning@gmail.com, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 1/9] Add yaffs Kconfig and Makefile
Date: Fri, 5 Nov 2010 09:58:38 +1300	[thread overview]
Message-ID: <201011050958.39020.manningc2@actrix.gen.nz> (raw)
In-Reply-To: <20101103174607.GA6777@kroah.com>

On Thursday 04 November 2010 06:46:07 Greg KH wrote:
> On Thu, Nov 04, 2010 at 05:53:16AM +1300, cdhmanning@gmail.com wrote:
> > From: Charles Manning <cdhmanning@gmail.com>
> >
> > Adding yaffs2 file system.
> >
> > Signed-off-by: Charles Manning <cdhmanning@gmail.com>
> > ---
> >  fs/yaffs2/Kconfig  |  190
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/yaffs2/Makefile |
> >   17 +++++
>
> Don't do this as your first patch, make it your last one.  Otherwise the
> build will break when you apply this one to the tree.
> Remember, we need to be able to have a correct build at every patch in
> the whole development series, otherwise tools like 'git bisect' will not
> work properly.

I left the actual hook in to the tree building to the last patch which changes 
fs/Kconfig and fs/Makefile.  Thus building the whole of Linux would not 
break.

I suppose the best is to put all the Kconfigs and Makefile changes in the last 
patch.

>
> Also, is your goal to get this cleaned up good enough to get it into .38
> in the "real" place in the kernel, or do you want to see it go through
> staging and take a bit longer to get everything cleaned up properly
> before moving to the "real" location?

My goal it to get this into mainline, .38 preferred.

I am a complete newbie when it comes to this process. What's the best path to 
getting there? 

My preference is to keep cleaning up code in yaffs.net and patching from there 
as this will keep the trees closer together and minimise clerical issues.

It is also a goal to keep the multi-kernel version of the code going in 
yaffs.net so  that there is always a backport on tap. This is an important 
issue for the embedded folk.

>From what you have said it sounds like skipping staging might be better, but I 
have insufficient understanding of the process to understand why. I'll talk 
to some people I know that understand this better.

Thanks

Charles


  parent reply	other threads:[~2010-11-04 20:58 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-03 16:53 [PATCH 0/9] Add yaffs2 file system cdhmanning
2010-11-03 16:53 ` [PATCH 1/9] Add yaffs Kconfig and Makefile cdhmanning
2010-11-03 17:46   ` Greg KH
2010-11-03 17:55     ` David Daney
2010-11-03 18:06       ` Greg KH
2010-11-04 20:58     ` Charles Manning [this message]
2010-11-04 22:36       ` Greg KH
2010-11-05  0:14         ` Ryan Mallon
2010-11-06  1:50   ` Valdis.Kletnieks
2010-11-07 20:59     ` Charles Manning
2010-11-07 21:45       ` Chris Snook
2010-11-07 22:22         ` Charles Manning
2010-11-08 10:24           ` Chris Snook
2010-11-08 21:22             ` Charles Manning
2010-11-08 22:15               ` Chris Snook
2010-11-03 16:53 ` [PATCH 2/9] Add yaffs allocator, bitmap and attrib source cdhmanning
2010-11-04 23:01   ` Jesper Juhl
2010-11-07 22:42     ` Charles Manning
2010-11-03 16:53 ` [PATCH 3/9] Add yaffs checkpointing, blockinfo, nameval and os context cdhmanning
2010-11-03 16:53 ` [PATCH 4/9] Add yaffs ecc, mtd access and nand abstraction code cdhmanning
2010-11-03 17:05   ` David Daney
2010-11-03 16:53 ` [PATCH 5/9] Add yaffs_guts.c cdhmanning
2010-11-03 16:53 ` [PATCH 6/9] Add some yaffs include files cdhmanning
2010-11-03 17:10   ` David Daney
2010-11-03 17:16     ` Charles Manning
2010-11-09 17:12   ` Arnd Bergmann
2010-11-03 16:53 ` [PATCH 7/9] Add yaffs tag access code cdhmanning
2010-11-03 17:16   ` David Daney
2010-11-03 17:17   ` Paulo Marques
2010-11-03 16:53 ` [PATCH 8/9] Add yaffs verification and version specific code cdhmanning
2010-11-03 16:53 ` [PATCH 9/9] Add yaffs kernel glue cdhmanning
2010-11-09 16:57   ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201011050958.39020.manningc2@actrix.gen.nz \
    --to=manningc2@actrix.gen.nz \
    --cc=cdhmanning@gmail.com \
    --cc=greg@kroah.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®