linux-ext4.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).