On Sat, Jun 7, 2008 at 9:49 AM, nathan binkert <[EMAIL PROTECTED]> wrote: >> Just another thought on this... although in an ideal world everyone >> would test their code thoroughly before pushing it, we know that >> doesn't always happen. I think we do need to distinguish at least two >> levels of stability; the version that most external people use that's >> been tested heavily (because most external people are using it), and >> the "bleeding edge" of the repo where we're committing. Is there an >> open source project that doesn't have "stable" and "development" >> versions? We might as well set up this structure from day 1, IMO. > BSD and linux don't work this way. There's only one real repository > and people send patches upstream as they're tested. > Mercurial doesn't work this way, there is a crew repository where > people play with stuff, but the official repository is the stable > repository.
So what do you consider all the -rcN Linux releases? > > I guess my feeling is that the main repo should be the stable repo. Maybe you misinterpreted my comment... I'm really talking about distinguishing stable vs development revs, not maintaining separate repos, as the rest of my email made clear. > You shouldn't push unless you're confident in your changes. This > seems to be the better model as the project gets larger and more > spread out. People can maintain their own unstable repositories in > separate groups that make sense. If we were all on the same sort of > project, the way it was when we were all at UM, it would make more > sense. Can't disagree with that, but as we get a larger user base we'll also get people using it in ways that aren't tested by the regressions (note our relationship with scons), so I think it's highly optimistic to think that just because we're confident means that it will work for everybody. > > >> 1. Seems like there's no need for a separate repo; we could just have >> a tag that's "latest stable" or something like that, and advance that >> tag as needed [...] > not terrible. I'd argue that the stable tag ought to move relatively > quickly, and we should either have some automated rule about moving it > (all regressions have passed including all long ones), or we should be > very active in moving it forward. The only sorts of things that are > going to be difficult in this model are very sweeping changes like my > change to all instances of events being scheduled, but I can do that > in a separate repository for the most part and by letting everyone > know before the final merge that it's coming. Relatively quickly, yes, but again, I'm hesitant to rely solely on our internal regression coverage. Also I think most users really don't need or want to upgrade that rapidly, and if we move things forward too quickly then that will discourage them from keeping up. How about a model where we set some target period for updating the stable pointer, and when that period has passed, we move the pointer up to where the repo was at at the beginning of the period, manually tweaking it if needed to encompass bug fixes? E.g., if the period is monthly, then at the beginning of August we update the stable pointer to roughly where we were at the beginning of July... though I'd prefer a slower pace, maybe every 3-6 months. Most of us will be using the bleeding edge anyway, so it won't affect us directly. Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
