[PATCH 1/3] TIPC: Removing EXPERIMENTAL label

[PATCH 1/3] TIPC: Removing EXPERIMENTAL label

[Jon Maloy]

With the latest series of patches from Paul Gortmaker and Allan
Stephens TIPC is now functionally mature and stable enough to
justify removal of the EXPERIMENTAL label.

Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
 net/tipc/Kconfig |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/tipc/Kconfig b/net/tipc/Kconfig
index 2c5954b..fdc1625 100644
--- a/net/tipc/Kconfig
+++ b/net/tipc/Kconfig
@@ -3,8 +3,8 @@
 #
 
 menuconfig TIPC
-	tristate "The TIPC Protocol (EXPERIMENTAL)"
-	depends on INET && EXPERIMENTAL
+	tristate "The TIPC Protocol"
+	depends on INET
 	---help---
 	  The Transparent Inter Process Communication (TIPC) protocol is
 	  specially designed for intra cluster communication. This protocol
-- 
1.7.9.5

[PATCH 2/3] TIPC: Adding new developers to maintainers list

[Jon Maloy]

Adding two very welcome new developers to maintainers list.
They have both worked with TIPC development for a while,
and are now ready to submit their own patches to net-next.

Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
 MAINTAINERS |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 490dd6e..6f0aec8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6683,7 +6683,9 @@ F:	include/linux/wl12xx.h
 
 TIPC NETWORK LAYER
 M:	Jon Maloy <jon.maloy@ericsson.com>
+M:	Erik Hugne <erik.hugne@ericsson.com>
 M:	Allan Stephens <allan.stephens@windriver.com>
+M:	Ying Xue <ying.xue@windriver.com>
 L:	netdev@vger.kernel.org (core kernel code)
 L:	tipc-discussion@lists.sourceforge.net (user apps, general discussion)
 W:	http://tipc.sourceforge.net/
-- 
1.7.9.5

Re: [PATCH 2/3] TIPC: Adding new developers to maintainers list

[David Miller]

From: Jon Maloy <jon.maloy@ericsson.com>
Date: Mon, 21 May 2012 01:59:13 -0400

> Adding two very welcome new developers to maintainers list.
> They have both worked with TIPC development for a while,
> and are now ready to submit their own patches to net-next.
> 
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>

Continuing to add windriver people to the maintainers list
is a bit of a joke don't you think?

No windriver person has submitted directly any of the hundreds
of patches that poor Paul Gortmaker had to backport and take
care of.

He is effectively the sole and only maintainer as far as I am
concerned.

[PATCH 3/3] TIPC: Stepping TIPC version to 2.1.0

[Jon Maloy]

Catch-up with out-of-tree version is done. We can go ahead
with more development.

Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
 net/tipc/core.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/tipc/core.h b/net/tipc/core.h
index 2a9bb99..3ab29bf 100644
--- a/net/tipc/core.h
+++ b/net/tipc/core.h
@@ -1,7 +1,7 @@
 /*
  * net/tipc/core.h: Include file for TIPC global declarations
  *
- * Copyright (c) 2005-2006, Ericsson AB
+ * Copyright (c) 2005-2006, 2012, Ericsson AB
  * Copyright (c) 2005-2007, 2010-2011, Wind River Systems
  * All rights reserved.
  *
@@ -56,7 +56,7 @@
 #include <linux/vmalloc.h>
 
 
-#define TIPC_MOD_VER "2.0.0"
+#define TIPC_MOD_VER "2.1.0"
 
 struct tipc_msg;	/* msg.h */
 struct print_buf;	/* log.h */
-- 
1.7.9.5

Re: [PATCH 3/3] TIPC: Stepping TIPC version to 2.1.0

[David Miller]

From: Jon Maloy <jon.maloy@ericsson.com>
Date: Mon, 21 May 2012 01:59:14 -0400

> Catch-up with out-of-tree version is done. We can go ahead
> with more development.
> 
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>

Again, I don't trust you, you and the windriver folks have haven't
submitted upstream TIPC patches for year, therefore I'd rather someone
I have an ongoing relation with, such as Paul, submit this stuff.

You can't ignore and write off upstream TIPC completely, then show up
out of the blue and start being the main source of changes.  That's
rude, and I simply won't allow that.

Re: [PATCH 1/3] TIPC: Removing EXPERIMENTAL label

[David Miller]

From: Jon Maloy <jon.maloy@ericsson.com>
Date: Mon, 21 May 2012 01:59:12 -0400

> With the latest series of patches from Paul Gortmaker and Allan
> Stephens TIPC is now functionally mature and stable enough to
> justify removal of the EXPERIMENTAL label.
> 
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>

I'll let Paul Gortmaker decide whether this is warranted or
not.

I don't really want to all of a sudden start seeing patches from
people like you and the windriver folks, who effectively wrote off
upstream and left poor Paul Gortmaker holding the bag and having to
take care of EVERYTHING.

You can't just do nothing for years, end up making someone else
do it, then say "Hey here I am, I feel like submitting upstream
patches now" after I've spent this entire time starting to trust
Paul for TIPC patches.

Re: [PATCH 1/3] TIPC: Removing EXPERIMENTAL label

[Paul Gortmaker]

[Re: [PATCH 1/3] TIPC: Removing EXPERIMENTAL label] On 21/05/2012 (Mon 02:39) David Miller wrote:

> From: Jon Maloy <jon.maloy@ericsson.com>
> Date: Mon, 21 May 2012 01:59:12 -0400
> 
> > With the latest series of patches from Paul Gortmaker and Allan
> > Stephens TIPC is now functionally mature and stable enough to
> > justify removal of the EXPERIMENTAL label.
> > 
> > Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
> 
> I'll let Paul Gortmaker decide whether this is warranted or
> not.

The EXPERIMENTAL thing has always been rather subjective, but
I'd like to see some level of confidence that a crafted up bogus
TIPC message can't be used to DOS a machine with active TIPC
connections before removing EXPERIMENTAL.  Maybe the current code
is OK as-is in this respect but I'd feel better knowing that it
had been audited with this exact kind of thing in mind.

> 
> I don't really want to all of a sudden start seeing patches from
> people like you and the windriver folks, who effectively wrote off
> upstream and left poor Paul Gortmaker holding the bag and having to
> take care of EVERYTHING.

To be fair, I should note that Al did a lot of work in the background
getting commits onto a modern baseline and answering all my questions
since the out of tree sourceforge mess was highlighted here on netdev.

> 
> You can't just do nothing for years, end up making someone else
> do it, then say "Hey here I am, I feel like submitting upstream
> patches now" after I've spent this entire time starting to trust
> Paul for TIPC patches.

I've been thinking about this off and on, and I'm wondering what to
suggest going forward.  Dealing with the backlog was largely going over
maintenance and bugfix type patches and sanitizing them for integration
upstream.  It largely boiled down to being able to tell a crap patch
from a good one that matched upstream expectations.  I figured I could
manage to not screw that up too badly, hence why I volunteered to assist
with the backlog.

But for new TIPC development features, future direction, and things like
that -- making the right call requires intimate understanding of TIPC
and its users, which is something that a maintainer should have but
something I know I don't have.  (A man has to know his limitations.)

In this context, I'm not talking about these three trivial patches; but
more complicated stuff that I imagine will be floated in the future.

To that end, I can still review and call out issues in a crap patch when
I see them.  But I'd like to see new stuff sent to netdev, so that folks
smarter than me have a chance to catch when a patch appears generally OK
but is architecturally the wrong direction etc.

Paul.

> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: [PATCH 1/3] TIPC: Removing EXPERIMENTAL label

[David Miller]

From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Thu, 24 May 2012 15:58:16 -0400

> But for new TIPC development features, future direction, and things like
> that -- making the right call requires intimate understanding of TIPC
> and its users, which is something that a maintainer should have but
> something I know I don't have.  (A man has to know his limitations.)
> 
> In this context, I'm not talking about these three trivial patches; but
> more complicated stuff that I imagine will be floated in the future.
> 
> To that end, I can still review and call out issues in a crap patch when
> I see them.  But I'd like to see new stuff sent to netdev, so that folks
> smarter than me have a chance to catch when a patch appears generally OK
> but is architecturally the wrong direction etc.

For maintainership, taste is more important than deep knowledge of the
specific technology.  Worst case you ask the submitter to explain the
background of their change more thoroughly and that information is an
absolutely requirement in the commit message and code comments
anyways.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: [PATCH 1/3] TIPC: Removing EXPERIMENTAL label

[Paul Gortmaker]

[Re: [PATCH 1/3] TIPC: Removing EXPERIMENTAL label] On 24/05/2012 (Thu 16:12) David Miller wrote:

> From: Paul Gortmaker <paul.gortmaker@windriver.com>
> Date: Thu, 24 May 2012 15:58:16 -0400
> 
> > But for new TIPC development features, future direction, and things like
> > that -- making the right call requires intimate understanding of TIPC
> > and its users, which is something that a maintainer should have but
> > something I know I don't have.  (A man has to know his limitations.)
> > 
> > In this context, I'm not talking about these three trivial patches; but
> > more complicated stuff that I imagine will be floated in the future.
> > 
> > To that end, I can still review and call out issues in a crap patch when
> > I see them.  But I'd like to see new stuff sent to netdev, so that folks
> > smarter than me have a chance to catch when a patch appears generally OK
> > but is architecturally the wrong direction etc.
> 
> For maintainership, taste is more important than deep knowledge of the
> specific technology.  Worst case you ask the submitter to explain the
> background of their change more thoroughly and that information is an
> absolutely requirement in the commit message and code comments
> anyways.

OK, what I'm hearing is that you'd prefer I continue to collect up TIPC
patches and issue pull requests for a while longer.  I can do that.  Any
specifics of how you'd like things done? -- e.g. if the reviews of new
TIPC development patches takes place here on netdev before I stage them,
will that create extra work for you dealing with them in patchworks?

Paul.

Re: [PATCH 1/3] TIPC: Removing EXPERIMENTAL label

[David Miller]

From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri, 25 May 2012 15:05:06 -0400

> OK, what I'm hearing is that you'd prefer I continue to collect up TIPC
> patches and issue pull requests for a while longer.  I can do that.  Any
> specifics of how you'd like things done? -- e.g. if the reviews of new
> TIPC development patches takes place here on netdev before I stage them,
> will that create extra work for you dealing with them in patchworks?

When you want the TIPC patches reviewed here you can simply post the
set, and since you're informing me how this will work I'll know that
you'll send me a pull request later, and therefore I can mark the
patches as "Awaiting Upstream" or similar in patchwork.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/