Rowland Penny <rpe...@samba.org> wrote: > The problem is that it is probably easier to start anew rather than > trying to update/maintain an existing project. You have to contact > the existing maintainer (and you could have problems actually > finding the maintainer), get their permission to update the package > or fix bugs and then do what you wanted to do in the first place.
And especially if it's to address things like changed kernel internals - in this case adding a lot of additional information/features. Often it can be the case that the old code isn't easily adapted in anything other than a "write whole new chunks from scratch" approach. By the time you've : made wholesale changes to the internal data structures (eg introducing flexibly sized arrays of values instead of fixed discrete values), made wholesale changes to the data collection routines (eg walking a tree of possible data values rather than reading a few hardcoded ones), and made wholesale changes to the UI (eg parsing new required options, outputting new (and variable) data values) - then it can often be a lot easier, cleaner, and less error prone to start again with a fresh sheet. How many times have we looked at something and though "if only we hadn't started from there". I've got that in the (new to us) house. The plumbing has quite a few "what were they thinking" 'features' - but stepping back, many of them make sense in that (for example) the bathroom plumbing was altered while there was still a hot water cylinder (& cupboard), later that cylinder was removed and a combi boiler fitted, it would have been disruptive to the (relatively newly tiled) bathroom to try and redo those parts of the previous work that no longer made sense. I'll be doing some more alterations myself, but this time I'll be in a position to rip a lot of it out and effectively start again - throwing out some of the historical baggage (I bet some of the plumbing is still pre-metric - ie 1/2" and 3/4" rather than 15mm and 22mm pipe). In other cases, it simply makes sense to gather a collection of "random stuff" into on integrated tool - I'm thinking about the "ip" command here. I bet there was a lot of duplicated stuff in the predecessors (eg route, ifconfig, et al) - with each util having similar code to (eg) interrogate the state of bits of the (IP) networking stack. In addition, it means having one tool (albeit a bigger one) to call on for a group of related functions - eg IP addressing and routing tables are closely and inextricably linked, why have two unrelated tools to manage them ? >> Get their permission? Aren't we using free software? > > If you want to update a packages code, you need to get at it, otherwise > it is called a fork, therefore you need the maintainers permission to > change it. If you don't get permission, then you need a new name - for the package and the binaries installed on the system - to avoid confusion. So then you have the same issue that people will complain "why did they have to change it ?". _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
