Just to add my two cents... as Ali said, Nilay's points are true but he is not the first to raise them; we have had multiple lengthy discussions on this list on defining an appropriate policy for regularly updating gem5-stable, only to have them all fall apart when it came to following through.
I'll differ semantically with Nilay and Andreas on a few points though. First, gem5-stable is stable in the sense that it changes much less frequently than gem5 (much much much less... too much less... but it does fit the definition of stable). Second, I'd say that gem5-stable is not a "separate repository", it really is just a specific revision of the gem5 tree. It's another clone of the same repo as gem5 (and is updated just by pulling from gem5 as Ali pointed out). It only looks like a separate repository given the way we expose it on the web site. I'm all for giving it another go... I don't think we even need to invent a new policy, just pull out the one we agreed on last time, but find a way to make it happen. If we conclude that we're incapable of implementing a policy (a reasonable conclusion based on history) and it's better to get rid of it than to leave it to get so stale, I'm OK with that too. Steve On Thu, May 23, 2013 at 8:56 PM, Ali Saidi <[email protected]> wrote: > You should be able to just push to it. > > Something like > > hg clone http://repo.gem5.org/gem5 > cd gem5 > hg update -r <rev that is good/stable/whatever> > hg push ssh://[email protected]/gem5-stable > > Ali > > > On May 23, 2013, at 10:49 PM, Nilay Vaish <[email protected]> wrote: > > > What do we need to do to update the repository? > > > > On Thu, 23 May 2013, Ali Saidi wrote: > > > >> 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 > >> > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > > > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
