diff mbox

Documentation: SubmittingPatches: mention our new Facebook group

Message ID 1396368515-8547-1-git-send-email-balbi@ti.com
State New
Headers show

Commit Message

Felipe Balbi April 1, 2014, 4:08 p.m. UTC
Now that we have a Facebook group thanks to Chris Mason,
it's best to mention it in our Documentation so people
know where to go.

Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 Documentation/SubmittingPatches | 39 +++++++++++++++++++++++++++------------
 1 file changed, 27 insertions(+), 12 deletions(-)

Comments

Steven Rostedt April 1, 2014, 4:23 p.m. UTC | #1
On Tue, Apr 01, 2014 at 11:08:35AM -0500, Felipe Balbi wrote:
> Now that we have a Facebook group thanks to Chris Mason,
> it's best to mention it in our Documentation so people
> know where to go.
> 
> Signed-off-by: Felipe Balbi <balbi@ti.com>

Liked-by: Steven Rostedt <rostedt@goodmis.org>

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
David Cohen April 1, 2014, 8:12 p.m. UTC | #2
Hi Felipe,

On Tue, Apr 01, 2014 at 11:08:35AM -0500, Felipe Balbi wrote:
> Now that we have a Facebook group thanks to Chris Mason,
> it's best to mention it in our Documentation so people
> know where to go.
> 
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>  Documentation/SubmittingPatches | 39 +++++++++++++++++++++++++++------------
>  1 file changed, 27 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index 26b1e31..a3ce332 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -155,7 +155,22 @@ be able to justify all violations that remain in your patch.
>  
>  
>  
> -5) Select e-mail destination.
> +5) Post your changes to our Facebook Group.
> +
> +We have a Facebook group at [1] where you *must* post your patches
> +to prior to getting them accepted by any maintainer. In the near
> +future, Facebook will become our only tool for patch reviewing
> +since the Kernel community has decided to embrace Web 2.0.
> +
> +Make sure to join the group and start posting your patches there,
> +instead of spamming everybody's inbox with countless patches each
> +day.
> +
> +[1] https://www.facebook.com/groups/linuxpatches/
> +
> +
> +
> +6) Select e-mail destination.

No e-mail destination, please. Just flag a fb buddy account in the post
you're sending the patch. Maintainer will see on his/her timeline updates.

Br, David

>  
>  Look through the MAINTAINERS file and the source code, and determine
>  if your change applies to a specific subsystem of the kernel, with
> @@ -184,7 +199,7 @@ discussed should the patch then be submitted to Linus.
>  
>  
>  
> -6) Select your CC (e-mail carbon copy) list.
> +7) Select your CC (e-mail carbon copy) list.
>  
>  Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org.
>  
> @@ -225,7 +240,7 @@ Trivial patches must qualify for one of the following rules:
>  
>  
>  
> -7) No MIME, no links, no compression, no attachments.  Just plain text.
> +8) No MIME, no links, no compression, no attachments.  Just plain text.
>  
>  Linus and other kernel developers need to be able to read and comment
>  on the changes you are submitting.  It is important for a kernel
> @@ -248,7 +263,7 @@ you to re-send them using MIME.
>  See Documentation/email-clients.txt for hints about configuring
>  your e-mail client so that it sends your patches untouched.
>  
> -8) E-mail size.
> +9) E-mail size.
>  
>  When sending patches to Linus, always follow step #7.
>  
> @@ -259,7 +274,7 @@ server, and provide instead a URL (link) pointing to your patch.
>  
>  
>  
> -9) Name your kernel version.
> +10) Name your kernel version.
>  
>  It is important to note, either in the subject line or in the patch
>  description, the kernel version to which this patch applies.
> @@ -269,7 +284,7 @@ Linus will not apply it.
>  
>  
>  
> -10) Don't get discouraged.  Re-submit.
> +11) Don't get discouraged.  Re-submit.
>  
>  After you have submitted your change, be patient and wait.  If Linus
>  likes your change and applies it, it will appear in the next version
> @@ -295,7 +310,7 @@ When in doubt, solicit comments on linux-kernel mailing list.
>  
>  
>  
> -11) Include PATCH in the subject
> +12) Include PATCH in the subject
>  
>  Due to high e-mail traffic to Linus, and to linux-kernel, it is common
>  convention to prefix your subject line with [PATCH].  This lets Linus
> @@ -304,7 +319,7 @@ e-mail discussions.
>  
>  
>  
> -12) Sign your work
> +13) Sign your work
>  
>  To improve tracking of who did what, especially with patches that can
>  percolate to their final resting place in the kernel through several
> @@ -399,7 +414,7 @@ tracking your trees, and to people trying to trouble-shoot bugs in your
>  tree.
>  
>  
> -13) When to use Acked-by: and Cc:
> +14) When to use Acked-by: and Cc:
>  
>  The Signed-off-by: tag indicates that the signer was involved in the
>  development of the patch, or that he/she was in the patch's delivery path.
> @@ -430,7 +445,7 @@ person it names.  This tag documents that potentially interested parties
>  have been included in the discussion
>  
>  
> -14) Using Reported-by:, Tested-by:, Reviewed-by: and Suggested-by:
> +15) Using Reported-by:, Tested-by:, Reviewed-by: and Suggested-by:
>  
>  If this patch fixes a problem reported by somebody else, consider adding a
>  Reported-by: tag to credit the reporter for their contribution.  Please
> @@ -486,7 +501,7 @@ idea reporters, they will, hopefully, be inspired to help us again in the
>  future.
>  
>  
> -15) The canonical patch format
> +16) The canonical patch format
>  
>  The canonical patch subject line is:
>  
> @@ -600,7 +615,7 @@ See more details on the proper patch format in the following
>  references.
>  
>  
> -16) Sending "git pull" requests  (from Linus emails)
> +17) Sending "git pull" requests  (from Linus emails)
>  
>  Please write the git repo address and branch name alone on the same line
>  so that I can't even by mistake pull from the wrong branch, and so
> -- 
> 1.9.1.286.g5172cb3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Theodore Ts'o April 1, 2014, 8:32 p.m. UTC | #3
One suggestion: the documentation should add a tip that if you can't
get someone to review your post, one option is to pay Facebook to
promote your post[1] so it shows more prominently (or at all) on more
kernel dvelopers' streams:

					- Ted

[1] http://hothardware.com/News/Facebook-Looking-at-New-Revenue-Stream-Pay-To-Promote-Friends-Posts-/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Jianyu Zhan April 1, 2014, 8:42 p.m. UTC | #4
On Wed, Apr 2, 2014 at 12:23 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> Liked-by: Steven Rostedt <rostedt@goodmis.org>

lovely Liked-by :-)

Liked-by:  Jianyu Zhan <nasa4836@gmail.com>



Regards,
Jianyu Zhan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Chris Mason April 1, 2014, 8:44 p.m. UTC | #5
On 04/01/2014 04:32 PM, Theodore Ts'o wrote:
> One suggestion: the documentation should add a tip that if you can't
> get someone to review your post, one option is to pay Facebook to
> promote your post[1] so it shows more prominently (or at all) on more
> kernel dvelopers' streams:

A fine idea!  I prefer the big newsfeed ads with video.  I really want 
to see the emotion behind your patch submission.

-chris

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Steven Rostedt April 1, 2014, 10:56 p.m. UTC | #6
On Tue, Apr 01, 2014 at 04:32:08PM -0400, Theodore Ts'o wrote:
> One suggestion: the documentation should add a tip that if you can't
> get someone to review your post, one option is to pay Facebook to
> promote your post[1] so it shows more prominently (or at all) on more
> kernel dvelopers' streams:
> 
> 					- Ted
> 
> [1] http://hothardware.com/News/Facebook-Looking-at-New-Revenue-Stream-Pay-To-Promote-Friends-Posts-/

The more likes you get (or pay for), the more likely your patch will be
pulled into mainline.

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Eric Dumazet April 1, 2014, 11:37 p.m. UTC | #7
On Tue, 2014-04-01 at 18:56 -0400, Steven Rostedt wrote:
> On Tue, Apr 01, 2014 at 04:32:08PM -0400, Theodore Ts'o wrote:
> > One suggestion: the documentation should add a tip that if you can't
> > get someone to review your post, one option is to pay Facebook to
> > promote your post[1] so it shows more prominently (or at all) on more
> > kernel dvelopers' streams:
> > 
> > 					- Ted
> > 
> > [1] http://hothardware.com/News/Facebook-Looking-at-New-Revenue-Stream-Pay-To-Promote-Friends-Posts-/
> 
> The more likes you get (or pay for), the more likely your patch will be
> pulled into mainline.


I do not want to ruin your day guys, but I own a patent on this whole
idea.

Fortunately it ends in 20 years, April 1st, 2034, so you only have to be
patient.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Felipe Balbi April 1, 2014, 11:38 p.m. UTC | #8
On Tue, Apr 01, 2014 at 04:37:02PM -0700, Eric Dumazet wrote:
> On Tue, 2014-04-01 at 18:56 -0400, Steven Rostedt wrote:
> > On Tue, Apr 01, 2014 at 04:32:08PM -0400, Theodore Ts'o wrote:
> > > One suggestion: the documentation should add a tip that if you can't
> > > get someone to review your post, one option is to pay Facebook to
> > > promote your post[1] so it shows more prominently (or at all) on more
> > > kernel dvelopers' streams:
> > > 
> > > 					- Ted
> > > 
> > > [1] http://hothardware.com/News/Facebook-Looking-at-New-Revenue-Stream-Pay-To-Promote-Friends-Posts-/
> > 
> > The more likes you get (or pay for), the more likely your patch will be
> > pulled into mainline.
> 
> 
> I do not want to ruin your day guys, but I own a patent on this whole
> idea.
> 
> Fortunately it ends in 20 years, April 1st, 2034, so you only have to be
> patient.

Darn it... By then we will all become Government-controlled zombies with
brain implants. Looking at the bright side, though, we will be able to
review a patch by just thinking about it.
Joe Perches April 1, 2014, 11:50 p.m. UTC | #9
On Tue, 2014-04-01 at 16:37 -0700, Eric Dumazet wrote:
> I do not want to ruin your day guys, but I own a patent on this whole
> idea.

phfft.

Betcha your implementation-free idea patent won't hold up.
Prior art and such.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
diff mbox

Patch

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 26b1e31..a3ce332 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -155,7 +155,22 @@  be able to justify all violations that remain in your patch.
 
 
 
-5) Select e-mail destination.
+5) Post your changes to our Facebook Group.
+
+We have a Facebook group at [1] where you *must* post your patches
+to prior to getting them accepted by any maintainer. In the near
+future, Facebook will become our only tool for patch reviewing
+since the Kernel community has decided to embrace Web 2.0.
+
+Make sure to join the group and start posting your patches there,
+instead of spamming everybody's inbox with countless patches each
+day.
+
+[1] https://www.facebook.com/groups/linuxpatches/
+
+
+
+6) Select e-mail destination.
 
 Look through the MAINTAINERS file and the source code, and determine
 if your change applies to a specific subsystem of the kernel, with
@@ -184,7 +199,7 @@  discussed should the patch then be submitted to Linus.
 
 
 
-6) Select your CC (e-mail carbon copy) list.
+7) Select your CC (e-mail carbon copy) list.
 
 Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org.
 
@@ -225,7 +240,7 @@  Trivial patches must qualify for one of the following rules:
 
 
 
-7) No MIME, no links, no compression, no attachments.  Just plain text.
+8) No MIME, no links, no compression, no attachments.  Just plain text.
 
 Linus and other kernel developers need to be able to read and comment
 on the changes you are submitting.  It is important for a kernel
@@ -248,7 +263,7 @@  you to re-send them using MIME.
 See Documentation/email-clients.txt for hints about configuring
 your e-mail client so that it sends your patches untouched.
 
-8) E-mail size.
+9) E-mail size.
 
 When sending patches to Linus, always follow step #7.
 
@@ -259,7 +274,7 @@  server, and provide instead a URL (link) pointing to your patch.
 
 
 
-9) Name your kernel version.
+10) Name your kernel version.
 
 It is important to note, either in the subject line or in the patch
 description, the kernel version to which this patch applies.
@@ -269,7 +284,7 @@  Linus will not apply it.
 
 
 
-10) Don't get discouraged.  Re-submit.
+11) Don't get discouraged.  Re-submit.
 
 After you have submitted your change, be patient and wait.  If Linus
 likes your change and applies it, it will appear in the next version
@@ -295,7 +310,7 @@  When in doubt, solicit comments on linux-kernel mailing list.
 
 
 
-11) Include PATCH in the subject
+12) Include PATCH in the subject
 
 Due to high e-mail traffic to Linus, and to linux-kernel, it is common
 convention to prefix your subject line with [PATCH].  This lets Linus
@@ -304,7 +319,7 @@  e-mail discussions.
 
 
 
-12) Sign your work
+13) Sign your work
 
 To improve tracking of who did what, especially with patches that can
 percolate to their final resting place in the kernel through several
@@ -399,7 +414,7 @@  tracking your trees, and to people trying to trouble-shoot bugs in your
 tree.
 
 
-13) When to use Acked-by: and Cc:
+14) When to use Acked-by: and Cc:
 
 The Signed-off-by: tag indicates that the signer was involved in the
 development of the patch, or that he/she was in the patch's delivery path.
@@ -430,7 +445,7 @@  person it names.  This tag documents that potentially interested parties
 have been included in the discussion
 
 
-14) Using Reported-by:, Tested-by:, Reviewed-by: and Suggested-by:
+15) Using Reported-by:, Tested-by:, Reviewed-by: and Suggested-by:
 
 If this patch fixes a problem reported by somebody else, consider adding a
 Reported-by: tag to credit the reporter for their contribution.  Please
@@ -486,7 +501,7 @@  idea reporters, they will, hopefully, be inspired to help us again in the
 future.
 
 
-15) The canonical patch format
+16) The canonical patch format
 
 The canonical patch subject line is:
 
@@ -600,7 +615,7 @@  See more details on the proper patch format in the following
 references.
 
 
-16) Sending "git pull" requests  (from Linus emails)
+17) Sending "git pull" requests  (from Linus emails)
 
 Please write the git repo address and branch name alone on the same line
 so that I can't even by mistake pull from the wrong branch, and so