>>>>> "MH" == Mark Hammond <mhammond@skippinet.com.au> writes: MH> [Greg writes] >> I'm not even going to attempt to try to define a hierarchy for >> all those modules. I count 137 on my local system. Let's say >> that I *do* try... some are going to end up "forced" rather than >> obeying some obvious grouping. If you do it a chunk at a time, >> then you get the obvious, intuitive groupings. Try for more, and >> you just bung it all up. MH> I agree with Greg - every module will not fit into a package. Sure. No one is arguing with that :-). Where I disagree with Greg, is that we shouldn't approach this piecemeal. A greedy algorithm can lead to a locally optimal solution that isn't the right for the whole library. A name or grouping might make sense on its own, but isn't sufficiently clear when taking all 137 odd modules into account. MH> But I also agree with Guido - we _should_ attempt to go through MH> the 137 modules and put the ones that fit into logical MH> groupings. Greg is probably correct with his selection for MH> "net", but a general evaluation is still a good thing. A view MH> of the bigger picture will help to quell debates over the MH> structure, and only leave us with the squabbles over the exact MH> spelling :-) x1.5 on this. I'm not sure which direction you ended up thinking this was (+ or -), but which ever direction it was I like it. Jeremy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4