From: Eric Sandeen <sandeen@sandeen.net>
To: Brian Norris <briannorris@chromium.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH xfsprogs] build: don't assume $BUILD_CC has fsmap.h just because $CC does
Date: Fri, 21 Sep 2018 15:53:38 -0500 [thread overview]
Message-ID: <771b2add-c502-b98f-5e2e-bceb9cadb5b5@sandeen.net> (raw)
In-Reply-To: <20180921193412.GA224566@ban.mtv.corp.google.com>
On 9/21/18 2:34 PM, Brian Norris wrote:
> On Fri, Sep 21, 2018 at 02:12:31PM -0500, Eric Sandeen wrote:
>> On 9/21/18 1:37 PM, Brian Norris wrote:
>>> Ping? Should I send a new version that combines our patches?
>>
>> Hi Brian - I'm not ignoring your patch, I've just been working on getting
>> libxfs synced for 4.19 before merging anything else - this is usually how
>> I work when patches come in near the beginning of a release cycle.
>> I'll revisit your patch & reach out to you if I have other questions or
>> suggestions when I get there, ok? Sorry for the delay.
>
> No problem at all. I don't think I understood the development patterns
> here anyway. It just wasn't clear if there was a next action for me.
> This makes it clear.
Eh, it changes from time to time and isn't exactly advertised, no worries.
And this time I'm a bit behind so xfsprogs is as well.
Normal xfsprogs cycle lately is something like:
Release the last version to match the last kernel, shortly after last kernel release
Start merging in libxfs changes from next devel kernel to prepare for next release, cut -rc0
Pick up most of the accumulated pending patches, cut an -rc1
do the normal soak/patch collection until release, rc's as needed
rinse, repeat.
-Eric
prev parent reply other threads:[~2018-09-22 2:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-06 18:35 [PATCH xfsprogs] build: don't assume $BUILD_CC has fsmap.h just because $CC does Brian Norris
2018-09-06 22:33 ` Eric Sandeen
2018-09-06 22:55 ` Brian Norris
2018-09-21 18:37 ` Brian Norris
2018-09-21 19:12 ` Eric Sandeen
2018-09-21 19:34 ` Brian Norris
2018-09-21 20:53 ` Eric Sandeen [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=771b2add-c502-b98f-5e2e-bceb9cadb5b5@sandeen.net \
--to=sandeen@sandeen.net \
--cc=briannorris@chromium.org \
--cc=linux-xfs@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;
as well as URLs for NNTP newsgroup(s).