On Mar 1, 2012, at 12:38 PM, Ken Moffat wrote:
> On Thu, Mar 01, 2012 at 11:30:00AM -0800, Qrux wrote:
>>
>> You're point seems to boil down to: "Don't overreact. 95% of stuff will
>> work."
>
> You could, with equal justification, have said the same about
> changes in many previous LFS releases.
Exactly right. So, I'd like to understand how the project has dealt with that.
Is there a process that's related to the release schedule? For example, (not
a suggestion, but an example of a procedure), are there any rules like: "If a
major change gets proposed and it's small enough to be a point-release, it will
start at the next cycle, but never mid-cycle."? What kind of guidelines or
rules are there?
> To test a new LFS build
I'm more interested in system testing, not just validating that the scripts run
if followed correctly. I assume most of the devs & RC-users are already do
that; I wouldn't be adding much.
I assume LFS is often not used -as is-, unless it's being run console-only
(which is usable, but seems like a harsh working environment). I'm guessing
that use-case is rare. I would also guess most people either run it headless
but connect via SSH, or run it with X; the point being, LFS is likely to be
used with something else on top of it. It has "consumers". And, I'm figuring
each release comes with some assurance that it works...Obviously it does
respect downstream; if it didn't, it wouldn't have users. But, it's also clear
there's nothing formal.
Can you elaborate on what the current process is for accepting a RC?
Q
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
