"Martin Krischik" wrote in message news:1432352.H7KnUpQB8m@linux1.krischik.com... > True. But It could be a starting point. You have to start somewhere or give > up and return to using C++. > I'm affraid I have to agree with Marin David Condic on this one. if we don't start it the right way we can't expect it to finish the right way either. Code wise well I'm sure that even if we dont all use the "Ada quality And Style" standards and suggestions, we all write decent code as in good variable naming, clear function names, etc etc....so maybe we can used that code itself, or play with it to make it comply to a given standard. But documentation wise, it's a different story. As Warren said on one of his messages, a lot of code I've seen to can't even answer the question "Why do I need this thing?" Others aren't clear as to how to use it, what are the pre requesits, and other "what I deem essential" information on the package and it's contents. I agree to not reinvent the wheel. But for the sake of the quality of the whole library, maybe we can take a chizel and pick at that wheel a little? :-). (again another cheap attempt at a metaphore ;-). The question is where do we draw the line? As in sure there's code outthere to sort an array many different ways, how do we determine that code is bad? Code should be acceptable provided it has clear names throughout the library for variables, procedures, functions, package names, task names etc etc....a minimal source code commenting scheme, and a minimal documentation (that is detailed enough so that anyone can read it and use the given library as it was meant to be used. What we could do perhaps is in teh revision process take anycode out there and first see how bad or good it is, see what needs to be added (comment wise) see what the doc says and conclude of it's viability as a library component. I dont know how everyone codes, but those that I do know how they code, so far, I'd throw their code right in the library with both my eyes closed :-). Documentation wise? Well that can vary from library to library. Sure that means more work for bigger packages, but for the sake of the quality of the whole library, this process should be close to mandatory. For documentation it doesn't really need to be a document file, could be a sample program that is documented comment wise enough to explain the where and how to's then either the author of the code or anyone that feels like it really could take that sample program, and form a decent documentation from it.....what the document should state? well that we can work on :-)....but as a basis it should say, What it is, How it's organized (a text hierarchy of packages might be quickly done and clear enough). Relationships between the parts Quick listing of procedures and function (as per the spec file). perhaps AdaBrowse can do a fine job of that without changes. How to's (how to use it) Discrepencies (if any) Pre-requisites to using the library...as such - Which OS it is supposed to work for - Which version of the OS and the Compiler basically. :-) -- St�phane Richard "Ada World" Webmaster http://www.adaworld.com