I On May 16, 2013, at 4:24 AM, Andreas Sandberg <[email protected]> wrote:
> On 05/15/2013 08:36 PM, Nilay Vaish wrote: >> I think we should either remove the repo gem5-stable or put in place some >> policy regarding gem5-stable. As of now, there is nothing stable about it. >> If we want to keep it, I suggest that we do the following: > > I definitely agree with you, the stable repository needs to go. The stable > version is probably way more buggy than the other version and it is a > constant source of confusion for new users. > > I really can't see the point of a completely separate repository. All other > software projects I have worked on usually just have a stable branch for each > major version and tags for each minor release. If I remember correctly, the > Linux kernel has a working repository (kind of like our working repo) and > each major release gets its own branch (e.g., linux-3.9.y), individual > releases are tags (e.g., v3.9.1). Linux actually has a separate repo where > stable releases are maintained, but I think that is just a way of reflecting > the fact that there are different maintainers of the stable repository. I also agree, but just as a warning, if you search the email achieves you'll find that we've come up with plans before. The issue has been sticking with them. I think even updating the stable repository every 3-4 months from the mainline would be reasonable, but it being over a year old isn't great. > >> a. update gem5-stable to gem5 every four months or so. Before updating, >> there would be a lean period of say 2-3 weeks when only bug-fixes would be >> committed to gem5. At the end of the period, gem5-stable would be updated to >> gem5. I propose updating gem5-stable on February 15th, June 15th and October >> 15th every year. We can have lean periods starting from 1st February, 1st >> June and 1st October. >> I'm quite happy with this approach. >> b. all patches that are committed to gem5 should be evaluated by developers >> as to whether they are bug fixes or not. If they are, and the bug is also >> present in gem5-stable, then those patches should also be committed to >> gem5-stable. I expect the extra work, in most cases, would be limited to >> applying the patch to gem5-stable and running the regression tests. > > I think we need a hybrid approach, let's call it c). Similar to a), we could > create a new stable branch (e.g., gem5-2013q1.x) 4 times or 2 times a year. > The only changes allowed to such a branch should be bug fixes (preferably > fixes that don't affect statistics). The branch is allowed to cool for say 2 > weeks before it is tagged for release (v2013q1.0). Once enough bug fixes have > accumulated, we just create a new release tag on the branch. Merging bug > fixes shouldn't be too hard since it would just be a matter of cherry-picking > changesets from the master branch. > > Unlike approach b), this approach wouldn't run the risk of diverging too much > from mainline, while at the same time providing stable releases at regular > intervals. I'm ok with this except that it's quite a it's more work, and we haven't even managed to just update the stable repository consistantly over the years. > We might want to take this opportunity to migrate our repositories to GIT. In > general, most people are more experienced at using GIT than Mercurial. There > are roughly 10x more GIT repos than HG repos [1], so it's probably safe to > assume that there is roughly 10x as many developers who know GIT. We already > have several internal GIT clones of gem5 in the group and I have seen at > least one other online (a port to Warped). Besides, it seems like most tools > have better support for Git (e.g., Jenkins has almost as many new Git > installations per months as there are Mercurial installations in total). our fencing about git continues :) Ali _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
