Re: [Netatalk-devel] Current Development Status

[Matthew K. <kel...@po...>]

Alex, 

Quite simply, Netatalk is a venerable package, used by a much more
diverse audience than you care to acknowledge. The ideas you propose are
great for small, fixed, homogeneous environments, but Netatalk needs to
support older Macs, Macs on different kinds of networks, Macs on
networks that don't even HAVE TCP/IP, Macs that aren't the
latest-and-greatest. I have clients in places that haven't even seen
MacOSX yet - their "new" PowerMACs are things of wonder to them. Guess
what they use for servers? BSD/Linux and Netatalk.

I don't know your background in computing, or development, esp.
distributed team development, but the things you're taking the most
issue with are classic conundrums that every application [suite] faces,
and deals with. Go tell the Samba group that they should stop supporting
Win9x. Go tell Apache they should stop supporting HTTP 1.0 browsers. Go
tell Linux Kernel devs that they should abandon anything other than 686
processors. 

Thomas' "degrading" discussions are trying to educate you as to why
things are the way they are. There is good reason against almost
everything you've proposed axing ... Proposed with no basis other than
YOU don't see a need for it. Several of the changes you've proposed will
even break in quazi-modern deployments (using SLP vs. ZeroConf isn't
THAT antiquated, for example).

The fact that nearly every Linux and BSD distribution includes Netatalk
- as old and crusty as it may appear to you - is testament to the fact
that it works very very well for an awful lot of people.

Feel free to fork, Alex. That's the bottom line. If Netatalk is in such
a shambles (it isn't) that you can't commit any code to it (which you
could) without hacking and slashing through venerable, well-tested,
well-built features, then fork it and torch it as you've proposed- and
build a better product that all 40+ downstream providers of Netatalk
would much rather include, that Cisco and Juniper routers would want to
include in their routers (oh wait, DDP Routing was first on your
chopping block), numerous NetApp-esque appliance vendors would rather
bundle.

Personally, I'd rather you put your energies into solving the problems,
you're having with Netatalk. I'd rather the energy spent on irrelevant
proposals be put into solving problems.  

I've tried to keep this whole thread as constructive and collegial as
possible, but you continue to make narrow-minded proposals and give
absolutely no reason for anything- And accusing Thomas (or any of us,
for that matter) of anything short of generously volunteering time he
doesn't have to help guide, explain, and advise - is just disgusting. 

This is, I hope, my last comment on this topic.

Matt 

On Fri, 2008-03-07 at 18:50 -0500, Alex deVries wrote:
> Thomas,
> 
> The goal of having ongoing support for as many features as possible is  
> a good one.  But it is sometimes difficult to achieve this.
> 
> Let's take the part about CAP volume migration.  It is conceivable  
> that there's someone out there trying to migrate such data, but it is  
> less and less likely (the last patches I could find were from 1995).   
> If you're going to keep that feature around, that means it should be  
> tested.  It certainly isn't impossible, but are we really going to  
> test a use case that's a decade old?  How many more features are there  
> like this?
> 
> The effect of all of this is that the developer resources will go to  
> sustaining these features rather than, say, emptying the bug list or  
> adding extended attribute support.  Especially with limited developer  
> bandwidth.
> 
> There isn't anything wrong with this conservative approach; this is  
> the right attitude to have when building software used in serious IT  
> organizations.
> 
> There's also a set of developers who are interested in some more  
> radical features (eg. Time Machine support) and willing to sacrifice  
> older features and stability.  As you've said quite clearly, this is  
> against the goals of netatalk.  Maybe having a different project with  
> these different goals isn't such a bad thing.  That's what I  
> interpreted in the earlier forking discussion.
> 
> I'm a bit concerned that the tone of these discussions is degrading  
> into an antagonistic argument.  I am, truly, encouraging netatalk  
> development.  And if I can figure out a way that I can contribute in a  
> way that's in sync with the objectives of the project, I will.
> 
> - Alex
> 
> On 7-Mar-08, at 5:01 PM, Thomas Kaiser wrote:
> 
> > Alex deVries wrote:
> >
> >> Based on our ability to test all of this, we may choose to drop
> >> support for things that we can't test (eg. CAP volume migration).
> >
> > Dropping features IMO is only applicable if
> >
> > * you can either ensure that no netatalk user world-wide is using a  
> > feature
> >  any more
> >
> > * or it is in conflict with something else and weighing pros and  
> > cons leads
> >  to a clear decision: we decided for example to drop symlink support  
> > inside
> >  netatalk sharepoints to ensure compatiblity with AFP specs and  
> > semantics.
> >  Some users weren't happy with that decision but IMO it has been the
> >  _right_ decision because violation of AFP specs is nothing we should
> >  support
> >
> > Regards,
> >
> > Thomas
> >
> >
> >
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Netatalk-devel mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netatalk-devel