| Message ID | 1337579954-17161-1-git-send-email-jon.maloy@ericsson.com |
|---|---|
| State | Rejected, archived |
| Delegated to: | David Miller |
| Headers | show |
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. -- 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
[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 -- 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
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. -- 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
[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. -- 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
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. -- 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
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
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(-)