Ag Hatzimanikas wrote these words on 05/28/06 09:47 CST: > Hal -> boot-procces -> udev -> kernel. > > Are you happy with this answer?
No. I'm more confused than before. You've thrown another thing (HAL) into the mix. And the order above makes absolutely no sense to me. (not that it is nonsensical, it's just I don't understand what you mean) My vote is neutral in that I vote to leave things the way they are, and let discussion happen on this list, and then an implementation when something is finalized. I don't understand the need for a "team" to do this. If it is a community thing, then let it remain a community thing. If it is something that needs to be determined by a select few, then that sounds to me as a fork. Just my thoughts. Bottom line is this: What does a "team" gain us, than cannot be done via community discussion? I don't count the issue with LFS/CLFS udev rules as being something that is resolved by a "team". The problem is deeper than that. I see the issue as a problem with coordination and communication between the groups. How does adding *another* group, or team, into the mix make it better? If only to solve a political disagreement, sort of like an arbitrator, then great, but the only disagreement I see is there are two factions that want "their" set of rules used. I don't see a need to form a team to create a third set of rules and *many other things* thrown in. If this team was to act as an arbitrator, and settle the Udev rules issue, then as I mentioned, great. But bestowing more responsibility beyond that, for things that are perfectly fine as they are, clouds the meaning to me. -- Randy rmlscsi: [bogomips 1003.27] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 09:57:00 up 16 days, 1:57, 1 user, load average: 0.24, 0.08, 0.02 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
