On Jun 7, 2008, at 2:09 PM, Steve Reinhardt wrote: >> 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.
To jump in here, the thing is we're not finding these bugs. Saying there needs to be 3 months of testing before we release something marked "stable" only works if its likely that the people running the bleeding edge are will find and fix bugs before they end up in changes encompassed by the stable tag. Other users found all these cache bugs, we didn't. I personally use the most basic memory hierarchy, it takes someone coming around and deciding that they want to look at configure Z that no one has ever tried before that exposes the problem. If that only happens to revisions that are marked stable its not clear that waiting 3 months helps at all. >> 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. That's ok, but the issue here is that merging patches really is an ugly business. > 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? It's not bad, patch sets can just be directories under .hg/patches. So you can have stable, internal, and mine. > > >> >> 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. Ali _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
