Matt Porter <[EMAIL PROTECTED]> writes: > So how does the freeze affect us? Are we a special case?
Yes, we are special in that we can make "upstream versions" at any point in the freeze, or even after release. > I'm concerned since I'm spending all my boot-floppies time fixing > issues related to the new busybox and leaving the two new feature > items (task installer and ftp/http install) alone for the moment. I > find it difficult to work on new features when that damn thing won't > even run like it did when we released 2.2.1. In retrospect, we screwed ourselves with these busybox updates. I didn't realize how much interdependancies we had between busybox and dbootstrap. So this is directly my fault. I'm sorry. (BTW, I was working on the assumption that the release manager would consult our opinion on freeze, but...). Matt, please advise -- should we back out busybox changes or forge ahead? I don't know how much further off we are from having a working core system with busybox 0.33. > I'll reiterate here that I can't believe the release manager is going to > freeze with boot-floppies in this state. I swear I saw Adam say at one > time that we wouldn't be ready for 2 months, but in another post he says > "feature complete" in 2 weeks. If I were king, I would put the freeze date at Jan 1. I believe it will take until Jan 1 to have a "production quality" boot-floppies. > Now who's adding the new features so things are ready in the projected > timeframe? Nobody. I think Adam (as our temporary/interim leader) needs > to express this to the release manager to put off the freeze. Dec 1st > would be much better, giving us time to fix dbootstrap into running order, > add the features that have been agreed upon (task gui, ftp/http inst, and > dhcp support), and only spend freeze time fixing bugs. I agree. I musta been crack-smoking if I ever said any date prior to Dec 1. -- .....Adam Di [EMAIL PROTECTED]<URL:http://www.onShore.com/>
