All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org, Zheng Liu <wenqing.lz@taobao.com>
Subject: Re: My current version of the inline data patches
Date: Tue, 21 May 2013 12:01:56 +0800	[thread overview]
Message-ID: <20130521040156.GC23907@gmail.com> (raw)
In-Reply-To: <20130521032657.GB586@thunk.org>

On Mon, May 20, 2013 at 11:26:57PM -0400, Theodore Ts'o wrote:
> The inlinie data patches, which have been updated to the latest master
> branch, can be found here:
> 
> https://github.com/tytso/e2fsprogs-inline-patch-queue
> 
> or
> 
> git://github.com/tytso/e2fsprogs-inline-patch-queue.git
> 
> 
> You can look at the history if you want to see what I've done.  The
> main thing to note is that while we are maintaining patches in a patch
> series, and while we are still trying to clean up the function
> interfaces, to fold any changes into parent patches.
> 
> So for example, I've folded all of the gcc -Wall cleanups that had
> been in "libext2fs-fix-some-warnings-from-gcc-Wall" into the patches
> that introduced the gcc warnings.  This makes it easier to review the
> patches, since we don't have the problem of a patch which has bugs or
> warnings which is fixed in a later patch.
> 
> When I did that, I found a change which was not related to gcc -Wall
> cleanups hiding in that patch.
> 
> I think I remember seeing other places where unrelated changes were
> glommed together into a single patch.  As we find them, we should
> split them into separate patches, again for ease of patch maintenance
> and improvements.
> 
> Again, my apologies for taking so long in getting these patches out
> there.  I really wanted to give you some examples in the kind of patch
> factoring and interface cleanups that I was hoping for before merging
> this support upstream.  Unfortuantely, I've been crazy busy these last
> few weeks.  I had hoped to put more work into this today, but I lost
> at least two hours due to a burst gas main which forced the
> evacuations of the offices.  :-(
> 
> (Turns out it's not just network fibers which emit backhoe pheromones,
> gas mains do as well.  :-)
> 
> I'll let you take the next whack at improving the patches.  My
> suggestion is that you create your own github repository, and update
> the patches using git.  What I generally do is to apply the patches
> using guilt (I suggest using v0.35 from git://repo.or.cz/guilt.git) by
> pulling down the github repository into an e2fsprogs repository at
> ".git/patches/inline".  Then take a look at first line of
> .git/patches/inline/series, which currently reads:
> 
> # BASE 4cf7a7014a209b82aada9b5d83ecdb9b07e60a1a
> 
> In the top of the e2fsprogs repository, type the commands:
> 
> % pushd .git/patches/inline ; sh timestamps ; popd
> % git branch inline 4cf7a7014a209b82aada9b5d83ecdb9b07e60a1a
> % git checkout inline
> % guilt push -a
> 
> This will apply all of the patches in .git/patches/inline (which you
> pulled down from github) to the e2fsprogs tree.  You can go back and
> forth by using the commands "guilt pop" and "guilt push".  To modify a
> patch, just edit the e2fsprogs files, and then use the command "guilt
> refresh --diffstat" to merge your edits into the patch file.  You can
> then commit changes to the patch queue by cd'ing into
> .git/patches/inline directory, and running standard "git commit"
> commands.  This way, when you send me an updated set of patches, I can
> look at the git log to see what changes you've made.
> 
> Does this make sense?  If not, please feel free to send me any
> questions you have.

Hi Ted,

Definitely it makes sense to me.  I really appreciate and thank you
for your suggestion.  Yes, I have used guilt to manage my patches for
a long time.  That is really useful for me.  I will revise every
single commit, and improve them.

Thanks,
                                                - Zheng

      reply	other threads:[~2013-05-21  3:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-27 10:44 [PATCH] libext2fs: do not print any error message from libext2fs Zheng Liu
2013-05-13 16:53 ` Zheng Liu
2013-05-21  2:36 ` Theodore Ts'o
2013-05-21  3:11   ` Zheng Liu
2013-05-21  3:26     ` My current version of the inline data patches Theodore Ts'o
2013-05-21  4:01       ` Zheng Liu [this message]

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=20130521040156.GC23907@gmail.com \
    --to=gnehzuil.liu@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=wenqing.lz@taobao.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.