On Thu, 05 Jan 2006 00:59:12 -0600 Bruce Dubbs <[EMAIL PROTECTED]> wrote:
> The way I look at it, we have four possibilities: > > 1. Ignore the issues. > 2. Add i18n / CLFS issues to each package as they come up. > 3. Have a section or appendix in the book to address the issues and > link each package to the appropriate part. This is the approach > that has been taken for i18n so far. > 4. Link each section of the book, as required, to an external > wiki/web page to address i18n or non-x86 issues. > > #1 is not really acceptable because it is not being responsive to the > community. > > #2 and #3 are essentially the same with the location within the book > different. They do nothing to address the workload issues. > > I lean toward #4 right now because it would basically take the BLFS > editors out of the non-mainline issues and let the experts in each > area update as needed. We also have additional servers available > that can distribute the load away from belgarath if necessary. > > I would like to open up a dialog of how to best handle the desires of > the community. Also, the above list is not necessarily exhaustive. > Other proposals would certainly be appropriate as a part of the > discussion. I'm no longer an editor primarily because I am uninterested in the full pain of maintaining the xml, with the full testing of the packages, with the need to maintain a LFS-compliant system to test it, with the sysVinit bootscripts and a whole lot more, that I shall not bore you with right now. :-) I'm also not really interested in hints any more for similar reasons, plus 'I hate text documents without diagrams'. But if there is a wiki which can be used to contibute ideas and fixes then I would hope to be active in the areas that I feel myself competant. There are even a number of packages that I don't think should be in the BLFS book, but that are quite hard to build/install/configure that would look good in a wiki. A wiki would give people like Alex a place to explain why our ideas don't work in UTF-8, and we might even learn a bit about that. I realise that I didn't directly address Bruce's question which is strictly speaking just about i18n/clfs issues (and I can't, as a x86 English speaker, contribute much there), but the same infrastructure might (with your permission) be used to extend BLFS seamlessly into areas that it can't cover well, such as alternative booting schemes, and their impact on the BLFS packages. So I like #4. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
