On Thu, Feb 25, 2010 at 12:33:37PM -0800, Stephens, Allan wrote:
quoted text
> > From: Neil Horman [mailto:nhorman@tuxdriver.com] 
> > Sent: Thursday, February 25, 2010 10:23 AM
> 
> [text deleted]
> 
> > To me I see that and read it as:
> > "We didn't have time to do things the way the Linux 
> > maintainers like to have them done, so we went off and did it 
> > on our own, figuring we'd get back to doing it the right way later"
> > 
> > Well, flash forward 1.5 years, and getting back to it never 
> > happened.  While I understand that can happen, it puts users 
> > in the lurch if they expect upstream to be the latest bits.  
> > As such, have you considered just dropping TIPC from upstream 
> > entirely?  I know that sounds a bit angry, I don't intend it 
> > to, I mean it in all seriousness.  Companies have constraints 
> > that sometimes conflict with upstream practices though, thats 
> > just a fact of life, and theres nothing we can really do 
> > about that.  But if the review/accptance criteria of upstream 
> > development doesn't fit into a companies budget or schedule, 
> > not doing kernel community development might be the best 
> > solution.  Doing so tells the distros that they have extra 
> > work to do if they want to incorporate/support tipc in their 
> > kernels, and frees your company to develop on its own 
> > schedule, and according to its own resources, while still 
> > being accessable to end users.  Of course, in so doing you 
> > don't get the maintenence changes that come with an ever 
> > evolving ABI/etc, but thats the price you would have to pay, 
> > and a decision you could make.
> > 
> > I'm not trying to tell you its the best solution, just an 
> > alternate option.
> > Honestly, what I'd like to see is all the remaining changes 
> > in TIPC 1.7 go in as individual commits, so that we have a 
> > good change history, and a resonable review on all the 
> > changes.  I know that takes longer but I think its the right 
> > solution.  I'll even volunteer to help, if that lightens your 
> > load any.  If you can provide me access to whatever scm you 
> > used (or even some modicum of changelog in a text file, so 
> > that we could try to match up changes with documentation), 
> > I'll happily start pulling stuff apart to get it upstream.
> 
> I can't argue with the basic thrust of your comments, Neil, nor with the
> similar comments David has made in his previous emails.  The current
> situation is certainly regrettable, and I think we're all in agreement
> that the best solution is to get the remainder of TIPC 1.7 into Linux as
> soon as possible (as individual patches, not a single mega-patch), then
> to limit any future changes to the upstream side of things.
> 
> I've got no problem with Neil's offer to assist in getting the necessary
> patches generated, as this will undoubtedly speed things along faster
> than anything I could do on my own.  (I suggest that we get started on
> this once we get the current oops situation resolved.)  This kind of
> offer to share the burden is to be commended, and is an example that
> other TIPC users should look to.
> 
Well, I'm glad to help, let me know what I can do, and what data you can put in
my hands to get it done.

FWIW, I'm looking over the missing TIPC_NET_MODE checks in the tarball, and I
think they're small enough that we can roll them in with the other changes to
the send path pretty easily.  I've also run accross a locking issue (just
theoretical, nothing I've demonstrated to myself yet).  But it appears to exist
in the 1.7 tarball as well as upstream.

I'll roll it all up and
post a omnibus patch to fix the opposes in the next day or two.

Neil

quoted text
> 
> > But if thats a one shot deal, and you believe that the next 
> > schedule crunch you have will result in your company making 
> > another out-of-tree update, then perhaps switching to that 
> > mode of out-of-tree development might be worth consideration.
> > 
> > Regards
> > Neil
> 
> Actually, we've got no plans to continue doing out-of-tree development
> on TIPC -- we've already suffered enough pain by following that route,
> and I certainly don't want to repeat the experience!  The upside of
> having done things out-of-tree in the past is that it gives us hard data
> we can use to squelch discussion the next time somebody suggests doing
> it again.
> 
> Regards,
> Al
>  
> 
--
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