linux-kernel - Re: [PATCH v7 1/2] spi: add support for DLN-2 USB-SPI adapter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 28 Nov 2014 18:35:07 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Laurentiu Palcu <laurentiu.palcu@...el.com>
Cc:	Samuel Ortiz <sameo@...ux.intel.com>,
	Lee Jones <lee.jones@...aro.org>,
	Johan Havold <johan@...nel.org>,
	Octavian Purdila <octavian.purdila@...el.com>,
	linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 1/2] spi: add support for DLN-2 USB-SPI adapter

On Fri, Nov 28, 2014 at 08:13:26PM +0200, Laurentiu Palcu wrote:
> On Fri, Nov 28, 2014 at 04:01:56PM +0000, Mark Brown wrote:

> > No, please don't - you're missing the point.  The point is that now Lee
> > has applied the other patch you're not sending two patches any more,
> > you're sending a single patch.  This isn't patch 1/2, it's just a single
> > patch by itself now.

> All I did was send new revisions of the 1/2 patch using the
> --in-reply-to option of git-send-email, with the message-id of the
> original version. I used to do this for other projects I contributed to,
> so I didn't have to re-send the entire series for just one patch that

The whole point is that you're not sending a series, you're just sending
one patch.

> needs to be changed. Mail clients, at least the ones I use (mutt,
> evolution), order the mails nicely and you have all the history in one
> thread. So, one can see the cover letter of the series and the other
> original patches in the series, together with the new revisions of the
> changed patch. Of course, if more patches needed change, I would re-send a new
> series.

Definitely do *not* do this, it makes the thread very hard to follow if
there are multiple versions - you end up with multiple versions of
various patches scattered through the thread and it can be very unclear
which versions are current.  If there's a lot of traffic things get
hidden way back when the original submission happened.

Fortunately I've deleted old parts of the thread so I didn't notice you
were doing this.

> So, Mark, can you please instruct me (a link to a page explaining the
> workflow would be fine too) what is the exact workflow you are/were
> expecting?

The patch submission workflow is covered in SubmittingPatches.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)