> My biggest worry about 3-6 months is that we often have fixes that are > important and more recent than 3-6 months. Beta 5 is barely three > months old and has at least two important patches, right?
I was just going to use that same evidence to argue the opposite... the fact that beta5 is 3 months old and we're still finding significant bugs (including the assertion violation that Sujay posted about yesterday, which coincidentally Brad had just run into as well) says to me that we don't want to consider anything as stable until it's been through at least 3 months of availability. > There are also in-tree > branches that can be maintained which are essentially special uses of > tags. Perhaps we should learn how those work, but I don't want to > maintain a separate stable version. Seems like the big thing is that we want to separate bug fixes to the stable rev from new features/enhancements that haven't been widely tested. One solution is along the lines of what you suggested... maybe we maintain the "bleeding edge" version as a public mq patch list, and the "stable" version is just what's fully committed to the repo. Bug fix patches can then bypass new-feature patches to get into the stable version more quickly. One thing we'd have to emphasize internally is that pushing to the public patch list should still be done only when you have the same level of confidence that you currently should have before pushing to the central repo. Another concern I have is that I haven't used multiple mq patchsets much... if I have this public patchset because I'm on the bleeding edge, plus maybe some internal company shared patchset for the stuff I'm working on with colleagues, plus my own patches for what I'm currently working on, how cumbersome does that get? > > Maybe we should open this part of discussion to m5-users. Explain > that we don't have tons of time to maintain old versions, and find out > how many people would track the current revs. If we narrow it down to a couple of concrete options and can't decide among them, then asking m5-users sounds fine. I'd rather not move a very general discussion over there though. Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
