[EMAIL PROTECTED] want to have our cake and eat it too. We hope you do too. We're planning to try an experiment to see if this is possible. Let us know if it works for you. We want a continuous flow of improvements on the trunk. Both the big stuff like Hyatt's stylesheet work, and the range of smaller but important work planned for 0.9.2. Nothing new here. But at the same time we also want a continued period of stability like we've been enjoying the last week or so. This is a bit new. We've said we want this before, but haven't done much to make it happen. So here's our experiment. Basically it boils down to (1) [EMAIL PROTECTED] monitoring and metering check-ins to the trunk for the next 2 weeks; and (2) moving up the date for the next milestone release to the end of this 2 week period. In other words, you'll need an "a=" from drivers to checkin on the trunk for the next 2 weeks. The resulting Mozilla 0.9.2 milestone will become a branch that will turn into something that we will use to do QA and get feedback data to validate or invalidate our process to see whether or not we can maintain enough stability for Netscape to do a release off of the trunk. What kinds of criteria will we use for checkins, you ask? Fixes that are obvious and low risk with little chance of regression are almost always accepted. Fixes that are a little more complex will have to be well tested and well-reviewed before they are accepted. Branch landings or large landings that do pop up on the radar will have to be really well tested and proven to be worth the possible risk in accepting them. We treat large landings like this as special right now so there isn't a large change in our policy in this regards except to say that we want to try and minimize the risk with them even more, if possible. Why now? Well, stability feels damn good right now. We've had a chunk of big landings recently, and haven't had a real period of stability to let us test and evaluate our progress toward Mozilla 1.0. The effect of the stability period in between the beginning of the 0.9.1 freeze and the time of the 0.9.1 branch has been wonderful. Mozilla seems to have become a really stable product because all of the hard work that engineers and the QA and bug triage folks have been putting in to make sure that the really bad crashes have had focus and have had time from the engineers to make sure they get identified and fixed. Second, we need to find ways to manage the tree that provide balance between needed new features and stability. And we need to fine-tune these techniques soon to help us get to Mozilla 1.0. This experiment may not be the right balance; and we're counting on your feedback to help us improve. But doing nothing and hoping that the tree miraculously remains stable seems like asking for trouble getting to Mozilla 1.0. Third, trying this experiment now instead of one or two or three weeks from now helps Netscape stay in sync with the trunk. Netscape has asked us to help them out with getting their next release after beta out the door. Their choices were to either use the 0.9.1 branch as the basis for both the beta release that they have planned and the next 'real' release after that or to do a release off of the trunk some time after 0.9.1 has been released. We ( drivers ) agreed that it was better that Netscape stay on the trunk if possible so that their efforts are directed at the Mozilla trunk and the trunk benefits from the cleanup and stability work that inevitably happens before a product release. So we'll be implementing this experiment without a period for critique or suggestions beforehand. This sucks, and apologies to all. But we'll be expecting feedback and trying to integrate it as fast as we can. --Chris
