> So what do you consider all the -rcN Linux releases? > > 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. I think I was just coming from the opposite side. I probably just didn't respond to your message very clearly. I'm ok with having stable vs development revs. I'm opposed to separate repos and I just want to make sure we're not going to go down that route. Stable revs do not add much overhead. Stable repo does.
> 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. I don't disagree with that. I suspect that we should post patches fairly frequently. It might not be a bad idea to have a crew repository that has outstanding patches applied to it so people can test them all. (It could be done by using mq in a clever way). > 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. 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? Seems that 3-6 should be a maximum (I'd argue 3 months), but any time there's something important, we should just move it. 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. 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. Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
