From: Eric Sandeen <sandeen@redhat.com>
To: Theodore Tso <tytso@mit.edu>
Cc: ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: patches in queue but missing from series?
Date: Sun, 14 Sep 2008 14:43:56 -0700 [thread overview]
Message-ID: <48CD859C.8070301@redhat.com> (raw)
In-Reply-To: <20080914213448.GB8706@mit.edu>
Theodore Tso wrote:
> On Sun, Sep 14, 2008 at 02:11:08PM -0700, Eric Sandeen wrote:
>> Looking at what's in the patch queue, but not in the series file:
>>
>> ext4-fix-hang-due-to-corrupted-jinode.patch
>> ext4-new-defm-options
>> ext4-online-resize-fix-for-group-descriptor-corruption.patch
>> Fix-EXT_MAX_BLOCK.patch
>> jbd2-dio-kjournal-race-EIO.patch
>> jbd-dio-kjournal-race-EIO.patch
>>
>> Some of these are probably intentional (I think Ted has the printk
>> throttling stuff queued up to send) but have any of these simply gotten
>> lost somehow? Or merged upstream (or obsoleted) but not removed?
>
> Well, all of the patches in the ext3 directory are non-ext4 patches
> which I sent to akpm on Friday or Saturday; I decided to check them
> into the patch queue to make sure they don't get lost. I'll remove
> them when they are confirmed in -mm. These would be:
>
>> ext2-printk-throttling
>> ext3_dx_readdir_hash_collision_fix.patch
>> ext3-printk-throttling
>> ext3_truncate_block_allocated_on_a_failed_ext3_write_begin.patch
>
> Some of the patches were ones that fixed bugs introduced in other
> patches, and were folded into a parent patch. This was the case for
> ext4-fix-hang-due-to-corrupted-jinode.patch, which was folded into the
> patch that ultimately became commit 678aaf48 in the mainline Linux
> tree.
Ok that's what I thought.
> Ext4-new-defm-options was a patch I was working on that never got
> finished. It probably shouldn't have gotten checked into the patch
> queue.
Ok.
> Girish's Fix-EXT_MAX_BLOCK.patch caused regression failures, so it was
> dropped from the patch series. I don't think anyone ever went back to
> figure out why it was causing the ext4 tree to blow up.
Ok. Maybe it'd be better for something like that to comment it out of
the patch series, with a reason why? *shrug*
> As far as jbd2-dio-kjournal-race-EIO.patch and
> jbd-dio-kjournal-race-EIO.patch are concerned,
> jbd2-dio-kjournal-race-EIO.patch doesn't even apply any more. I'm
> guess it was fixed in some other way for jbd2. It looks the jbd patch
> could apply, but if it's still a valid fix, it should be fed through
> akpm. Mingming, do you know what the status of these two patches are?
>
> - Ted
Great - owners looking over these orphaned/lost patches is probably the
best approach. :)
Thanks,
-Eric
next prev parent reply other threads:[~2008-09-14 21:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-14 21:11 patches in queue but missing from series? Eric Sandeen
2008-09-14 21:34 ` Theodore Tso
2008-09-14 21:43 ` Eric Sandeen [this message]
2008-09-15 6:32 ` Andreas Dilger
2008-09-15 18:10 ` Mingming Cao
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=48CD859C.8070301@redhat.com \
--to=sandeen@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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.