From: Willy Tarreau <w@1wt.eu>
To: Mariusz Gorski <marius.gorski@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 4/9] staging: panel: Use defined value or checking module params state
Date: Thu, 27 Nov 2014 22:05:21 +0100 [thread overview]
Message-ID: <20141127210521.GE23012@1wt.eu> (raw)
In-Reply-To: <20141127195054.GA14536@firebird>
On Thu, Nov 27, 2014 at 08:50:55PM +0100, Mariusz Gorski wrote:
> > And the reason I got confused was because you didn't label your second
> > set of patches "v2", which it was, I saw two separate series, one with a
> > few patches, and then 2 sets of 9, the second set labeled "v2" so I
> > thought they were independant. Please think of the poor maintainer who
> > has to decipher things like this when you send them out...
>
> I'm confused right now. As you say, first I've sent a patchset of 4:
> https://lkml.org/lkml/2014/11/11/963
>
> Then, a couple of days later, I've sent the initial patchset of 9:
> https://lkml.org/lkml/2014/11/18/922
>
> And a day I've sent a fixed version of the above patchset, labeled with v2:
> https://lkml.org/lkml/2014/11/19/653
>
> Isn't this the right way to do? I still don't get my mistake. Because
> what I was just about to do is to resend the v2 patchset, but now I'm
> not sure anymore if this is what I'm supposed to do.
>
> BTW: Out of these 3 patchsets, 1st and 3rd should be applied.
Mariusz, for people who have to parse hundreds to thousands of e-mails
a day, dealing with non-trivial operation modes like this is never easy.
I think (I'll let Greg suggest what he prefers) that the most reliable
thing to do *right now* is to rebase your tree on top of Greg's staging
tree, and you send the resulting series (what you apply *after* staging)
at once, maybe even tagged as v3 to avoid any confusion.
Sometimes for the recipient, things apparently as simple as sorting
e-mails by subjects to find something can cause some confusion when
it's not obvious what replaces what, and tagging with the version or
ensuring that each series is different enough helps avoiding this.
If you need any help, contact me off-list and I'll gladly help you.
Don't worry, issues like this commonly happen and will happen again,
whatever you do against them will only reduce the likeliness that
they happen again (and that's important to care about this) :-)
Thanks,
Willy
next prev parent reply other threads:[~2014-11-27 21:05 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-19 20:38 [PATCH v2 0/9] staging: panel: Refactor panel initialization Mariusz Gorski
2014-11-19 20:38 ` [PATCH v2 1/9] staging: panel: Set default parport module param value Mariusz Gorski
2014-11-19 20:38 ` [PATCH v2 2/9] staging: panel: Call init function directly Mariusz Gorski
2014-11-19 20:38 ` [PATCH v2 3/9] staging: panel: Remove magic numbers Mariusz Gorski
2014-11-19 20:38 ` [PATCH v2 4/9] staging: panel: Use defined value or checking module params state Mariusz Gorski
2014-11-19 21:10 ` Willy Tarreau
2014-11-26 21:58 ` Greg Kroah-Hartman
2014-11-27 13:26 ` Mariusz Gorski
2014-11-27 15:24 ` Greg Kroah-Hartman
2014-11-27 15:57 ` Greg Kroah-Hartman
2014-11-27 16:14 ` Willy Tarreau
2014-11-27 16:28 ` Greg Kroah-Hartman
2014-11-27 19:50 ` Mariusz Gorski
2014-11-27 21:05 ` Willy Tarreau [this message]
2014-11-27 21:10 ` Fabio Estevam
2014-11-28 20:32 ` Greg Kroah-Hartman
2014-11-28 20:57 ` Mariusz Gorski
2014-11-28 22:14 ` Greg Kroah-Hartman
2014-11-19 20:38 ` [PATCH v2 5/9] staging: panel: Start making module params read-only Mariusz Gorski
2014-11-19 20:38 ` [PATCH v2 6/9] staging: panel: Make two more " Mariusz Gorski
2014-11-19 21:11 ` Willy Tarreau
2014-11-19 20:38 ` [PATCH v2 7/9] staging: panel: Refactor LCD init code Mariusz Gorski
2014-11-19 21:11 ` Willy Tarreau
2014-11-19 20:38 ` [PATCH v2 8/9] staging: panel: Remove more magic number comparison Mariusz Gorski
2014-11-19 21:11 ` Willy Tarreau
2014-11-19 20:38 ` [PATCH v2 9/9] staging: panel: Move LCD-related state into struct lcd Mariusz Gorski
2014-11-19 21:12 ` [PATCH v2 0/9] staging: panel: Refactor panel initialization Willy Tarreau
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=20141127210521.GE23012@1wt.eu \
--to=w@1wt.eu \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marius.gorski@gmail.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