akhiezer wrote: >> Date: Fri, 21 Feb 2014 13:10:17 -0600 >> From: Bruce Dubbs <[email protected]> >> To: LFS Developers Mailinglist <[email protected]> >> Subject: [lfs-dev] Outstanding tickets >> >> I know I said we are in a package freeze, but as discussed on BLFS: >> >> Armin said: >> I believe we need a policy to exactly define what exactly "package >> freeze" means. >> >> And I responded: >> It means don't upgrade a package unless we talk it over and agree that >> it can be upgraded without creating additional work during the release >> testing period. >> > . > . >> >> On the other hand, we could just continue to hold off until after 7.5 is >> released. >> >> I'm open to either alternative. >> > > > Seems a bit over-obvious to say, but: isn't it better to freeze the lfs > part and then - say approx 2 weeks later - freeze the blfs part; lfs is, > after all, the foundation for the blfs part.
The problem is that no matter how we do it, upstream keeps making new releases. I'm fairly confident that LFS is pretty solid. If it were only LFS, the 'freeze' would be shorter. What we really need to do is freeze development tools and libraries. The likelihood of something like a grep upgrade affecting the rest of LFS or BLFS is pretty small. On the other hand, a change in gcc would require complete retesting. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
