Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [PATCH v2] docs/manual: document the new patch naming convention
@ 2014-10-14  7:40 Yann E. MORIN
  2014-10-27  0:17 ` Samuel Martin
  0 siblings, 1 reply; 4+ messages in thread
From: Yann E. MORIN @ 2014-10-14  7:40 UTC (permalink / raw)
  To: buildroot

To ease generating patches, we now use a naming convention that is in
line with what git-format-patch does, that is:
  - do not prefix patches with the package name
  - prefix patches with a 4-digit mber
  - start numbering at 0001

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Samuel Martin <s.martin49@gmail.com>

---
Changes v1 -> v2:
  - rewprd slightly  (Thomas DS)
---
 docs/manual/patch-policy.txt | 21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/docs/manual/patch-policy.txt b/docs/manual/patch-policy.txt
index 745f58d..6e27e71 100644
--- a/docs/manual/patch-policy.txt
+++ b/docs/manual/patch-policy.txt
@@ -31,16 +31,23 @@ Most patches are provided within Buildroot, in the package
 directory; these typically aim to fix cross-compilation, libc support,
 or other such issues.
 
-These patch files should be named +<packagename>-<number>-<description>.patch+.
-
-A +series+ file, as used by +quilt+, may also be added in the
-package directory. In that case, the +series+ file defines the patch
-application order.
+These patch files should be named +<number>-<description>.patch+.
 
 .Notes
 - The patch files coming with Buildroot should not contain any package version
-reference in their filename.
-- The field +<number>+ in the patch file name refers to the 'apply order'.
+  reference in their filename.
+- The field +<number>+ in the patch file name refers to the 'apply order',
+  and shall start at 1; It is preferred to pad the number with zeros up to 4
+  digits, like 'git-format-patch' does. E.g.: +0001-foobar-the-buz.patch+
+- Previously, it was mandatory for patches to be prefixed with the name of
+  the package, like +<package>-<number>-<description>.patch+, but that is
+  no longer the case. Existing packages will be fixed as time passes. 'Do
+  not prefix patches with the package name.'
+- Previously, a +series+ file, as used by +quilt+, could also be added in
+  the package directory. In that case, the +series+ file defines the patch
+  application order. This is deprecated, and will be removed in the future.
+  'Do not use a series file.'
+
 
 ==== Global patch directory
 
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* [Buildroot] [PATCH v2] docs/manual: document the new patch naming convention
  2014-10-14  7:40 Yann E. MORIN
@ 2014-10-27  0:17 ` Samuel Martin
  0 siblings, 0 replies; 4+ messages in thread
From: Samuel Martin @ 2014-10-27  0:17 UTC (permalink / raw)
  To: buildroot

On Tue, Oct 14, 2014 at 9:40 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> To ease generating patches, we now use a naming convention that is in
> line with what git-format-patch does, that is:
>   - do not prefix patches with the package name
>   - prefix patches with a 4-digit mber
>   - start numbering at 0001
>
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Peter Korsgaard <jacmet@uclibc.org>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
> Cc: Arnout Vandecappelle <arnout@mind.be>
> Cc: Samuel Martin <s.martin49@gmail.com>

Acked-by: Samuel Martin <s.martin49@gmail.com>

-- 
Samuel

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Buildroot] [PATCH v2] docs/manual: document the new patch naming convention
@ 2014-12-05 18:06 Yann E. MORIN
  2014-12-07 20:32 ` Thomas Petazzoni
  0 siblings, 1 reply; 4+ messages in thread
From: Yann E. MORIN @ 2014-12-05 18:06 UTC (permalink / raw)
  To: buildroot

To ease generating patches, we now use a naming convention that is in
line with what git-format-patch does, that is:
  - do not prefix patches with the package name
  - prefix patches with a 4-digit mber
  - start numbering at 0001

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Samuel Martin <s.martin49@gmail.com>

---
Changes v1 -> v2:
  - reword slightly  (Thomas DS)
---
 docs/manual/patch-policy.txt | 21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/docs/manual/patch-policy.txt b/docs/manual/patch-policy.txt
index 745f58d..6e27e71 100644
--- a/docs/manual/patch-policy.txt
+++ b/docs/manual/patch-policy.txt
@@ -31,16 +31,23 @@ Most patches are provided within Buildroot, in the package
 directory; these typically aim to fix cross-compilation, libc support,
 or other such issues.
 
-These patch files should be named +<packagename>-<number>-<description>.patch+.
-
-A +series+ file, as used by +quilt+, may also be added in the
-package directory. In that case, the +series+ file defines the patch
-application order.
+These patch files should be named +<number>-<description>.patch+.
 
 .Notes
 - The patch files coming with Buildroot should not contain any package version
-reference in their filename.
-- The field +<number>+ in the patch file name refers to the 'apply order'.
+  reference in their filename.
+- The field +<number>+ in the patch file name refers to the 'apply order',
+  and shall start at 1; It is preferred to pad the number with zeros up to 4
+  digits, like 'git-format-patch' does. E.g.: +0001-foobar-the-buz.patch+
+- Previously, it was mandatory for patches to be prefixed with the name of
+  the package, like +<package>-<number>-<description>.patch+, but that is
+  no longer the case. Existing packages will be fixed as time passes. 'Do
+  not prefix patches with the package name.'
+- Previously, a +series+ file, as used by +quilt+, could also be added in
+  the package directory. In that case, the +series+ file defines the patch
+  application order. This is deprecated, and will be removed in the future.
+  'Do not use a series file.'
+
 
 ==== Global patch directory
 
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* [Buildroot] [PATCH v2] docs/manual: document the new patch naming convention
  2014-12-05 18:06 [Buildroot] [PATCH v2] docs/manual: document the new patch naming convention Yann E. MORIN
@ 2014-12-07 20:32 ` Thomas Petazzoni
  0 siblings, 0 replies; 4+ messages in thread
From: Thomas Petazzoni @ 2014-12-07 20:32 UTC (permalink / raw)
  To: buildroot

Dear Yann E. MORIN,

On Fri,  5 Dec 2014 19:06:24 +0100, Yann E. MORIN wrote:
> To ease generating patches, we now use a naming convention that is in
> line with what git-format-patch does, that is:
>   - do not prefix patches with the package name
>   - prefix patches with a 4-digit mber
>   - start numbering at 0001
> 
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Peter Korsgaard <jacmet@uclibc.org>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
> Cc: Arnout Vandecappelle <arnout@mind.be>
> Cc: Samuel Martin <s.martin49@gmail.com>

Applied, thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-12-07 20:32 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-05 18:06 [Buildroot] [PATCH v2] docs/manual: document the new patch naming convention Yann E. MORIN
2014-12-07 20:32 ` Thomas Petazzoni
  -- strict thread matches above, loose matches on Subject: below --
2014-10-14  7:40 Yann E. MORIN
2014-10-27  0:17 ` Samuel Martin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox