Alexander E. Patrakov wrote: > Please subtract the number that want to use the LiveCD to cover LFS bugs, > don't > realize the inherent incompatibility of LFS with 64-bit hosts (IMHO, the fact > that LFS doesn't mention it counts as a bug), or don't know how to apt-get > install build-essential.
How in the world am I supposed to do that? Do you know the skill-level of every individual that commented in every list? Even if I add your vote to bring the 'drop it party' up to 3 (I could also add mine in favor of keeping the project, which I don't need to) and I stick to only people whose skill level I know, the majority are still voting to keep the project. As an aside, I fully disagree with your inflexible stance on who is 'allowed' to use either LFS or the LiveCD, or whose opinion on either product counts. The prerequisites stated in LFS are _suggested guidelines_. Nowhere does it say that people that don't meet those prerequisites are not free to use LFS or the CD, or that their experience with it is invalid. If someone who had just encountered a PC 2 weeks ago stumbled onto LFS, managed to work their way through it and came out the other end successful, I'd applaud them! Sure, they wouldn't have approached LFS the way it was intended, but if they learned something, the main goal has been reached. Obviously they are intelligent and determined enough, and very likely they will continue to learn and grow. Therefore, their opinion and feedback is just as valuable. And think of the reasons why those guidelines exist in the first place! First and foremost, isn't it because we want the reader to be successful in their experience? After that objective, IMHO, comes the secondary purpose that we as developers can't be responsible for the experience of every person who decides to start down the LFS path. There is nothing that requires us to provide more support to those who should have read more first. Far better for you to ignore them then to make judgment calls on who is 'allowed' to use the product or express their opinion about it. > Then we need a procedure to deal with feature requests ("reject outright" > also > counts as a procedure). Also we need a procedure to determine what counts as > a > feature request and what doesn't (e.g., what to do with net-firmware, > scsi-firmware and the numerous kernel patches and extra drivers for new > hardware?) Agreed. > This is incompatible with the "strictly adhere to LFS" goal, because LFS has > no > package management except "rebuild everything once a day". Note that I make > no > statement about the relative merit of these two incompatible goals. I suppose so. Although, the way I was perceiving it: * The configure and make arguments do not change so there is no difference in the binaries produced * The install arguments do not change so the binary locations are the same * All we really do is package up and log Isn't it still adhering strictly enough to LFS to count? Granted, this may not meet what is truly considered package management in a distro sense, but it would still ease development, and help in allowing further customization. >> * Add an LFS-style document to the project that teaches how to create a >> LiveCD from scratch. > > IMHO, this would line up with the rest of the project nicely, and doesn't > exclude actually providing some binary CD. Yes, this is turning out to be a good suggestion, I believe. >> * Devise methods for users to more easily provide feedback and make it >> easier to contribute as a whole. > > This also should include stating what kind of feedback is needed. So far, > there > were only "please add this package" requests, borderline cases like "old > laptops > with the OnTrack disk manager doen't see the partitions with libata" (solved > by > adding kpartx) and a few bug reports. Agreed. -- JH -- http://linuxfromscratch.org/mailman/listinfo/livecd FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page