Sort of a multi-reply here... On Sat, Jun 7, 2008 at 11:36 AM, Ali Saidi <[EMAIL PROTECTED]> wrote: > > 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.
That's a reasonable argument... it's not clear how many people would use bleeding edge vs. stable. >> 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. [...] > It's not bad, patch sets can just be directories under .hg/patches. So > you can have stable, internal, and mine. Aren't these statements contradictory? If you have the patch sets under separate subdirs, can they come from different repos? Would you still have to manually merge the series file? I don't totally blame Gabe for having the willies about this. On Sat, Jun 7, 2008 at 11:58 AM, Ali Saidi <[EMAIL PROTECTED]> wrote: > The problem I have with as set of patches is that someone then has to > go an get M5 and get this set of patches and apply them. It just > raises the barrier to entry even more. If you're not using the "bleeding edge" version then you wouldn't need/want the patches, so I don't think it raises the barrier to novices. It would make transitioning to the bleeding edge a little more complicated, but nothing we can't overcome with a good FAQ. (Not to say I'm wedded to this idea... I still think your other objections are valid.) On Sat, Jun 7, 2008 at 12:26 PM, nathan binkert <[EMAIL PROTECTED]> wrote: > So, do you want to maintain a separate branch of all of those fixes > for several months? I don't. Me neither... that's why I brought up the idea of using a patch queue. > Many of those bugs would also not be found if > it weren't for people other than us, because as you say we don't do > enough testing on our own since we don't use it in a wide enough range > of circumstances. That's basically the same argument Ali made... I guess the key thing with Linux is that there are enough random people who use the release candidates to make them valid testing vehicles. My main fear is that if all we offer as a default download is the tip, then if something broken gets in there and someone downloads m5 for the first time and it doesn't work, that's not good. Maybe Nate's idea of automatically advancing the stable pointer once we've run the fullest possible set of regressions is the right way to go, and we can try harder to make sure that when we see some configuration break we create a regression test for it. That would go along with making the test framework a little more flexible, so we can have regressions that depend on files we can't export (like SPEC) that only run when appropriate, and maybe some staging mechanism that lets us run 1/N of the really long regressions every day instead of trying to do them all once every N days. Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
