We've had multiple discussions on this (search the list archives for m5-stable and you should find them). We had some debate about how frequently m5-stable should be updated, and how long we want a changeset to mature in m5 before we consider promoting it to m5-stable, but I think we found some values everyone was content with last time... something like every 6 months we'll update m5-stable to the last working revision more than 1 month old, or something like that. (Or maybe it was 3/1, or 6/2, I forgot.) But as Ali says, the catch in automating this process is identifying the "last working revision"... we could use the regression tests to help narrow that down, but there are a lot of bugs that get pushed that aren't caught by the regression tester, so I wouldn't want to rely solely on that. If we had a better bug-tracking system so we could record facts like "changeset Y fixes a bug introduced in changeset X" then we could automatically exclude changesets between X and Y, but we don't have that.
Steve On Tue, Mar 29, 2011 at 6:38 PM, Ali Saidi <sa...@umich.edu> wrote: > You could do that, but there is no guarentee you'd pick a non-broken version > to push. We wouldn't want to push anything from the last week with all the > compilation issues. > > Ali > > On Mar 29, 2011, at 6:19 PM, Korey Sewell wrote: > >>> I'd prefer to see us just start updating m5-stable more regularly so >>> it can fulfill its original purpose. We keep discussing this but >>> never actually follow through. >> >> Is this any harder than just setting up a cronjob to push whatever is >> in m5-dev to m5-stable once per month (?) >> >> - Korey >> _______________________________________________ >> m5-dev mailing list >> m5-dev@m5sim.org >> http://m5sim.org/mailman/listinfo/m5-dev >> > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
