>>>>> "Roland" == Roland Mainz <roland.mainz at nrubsig.org> writes:
Roland> AFAIK there are no definitive rules which should be picked and Roland> which not - and stripping all "unused" files may only cause lots Roland> of trouble later (which would be my burden to get this somehow Roland> repaired, over and over again I don't know of any written guidelines. The principles that I would apply if it were my project are - if the file is clearly not useful, delete it. The ON gate already requires a couple GB; let's not add to that without good reason. - if the file is required for the build, or if it will be used (perhaps after some tweaking) for upstream updates, then keep it. - if the file is useful but not actually built (e.g., the sh.1 man page that you mentioned), it may be worth keeping. But the source tree should be organized so that someone not on the project team can easily figure out what's actually built and what's just reference material. Ideally, this would be done by placing reference materials in their own directory. - nothing is cast in stone. If we delete a file and it turns out later to be useful, we can change our minds and put the file back in the source tree. That said, I can see how keeping all the upstream files, using the upstream source layout, would simplify future updates. I think the current items in the exception list (Perl, GRUB, tcpd, etc) are sufficient precedent to keep the ksh93 files. We might decide that we don't like that precedent and that we need to rethink the way we handle components with upstream updates, but let's not force the ksh93 team to wait until we've done that work. I still would really like to see a README or something to indicate that the <library>/common/Makefile files are unused. mike
