Thanks! Steve
On Fri, Jun 14, 2013 at 3:05 PM, Nilay Vaish <[email protected]> wrote: > So I am going to update the gem5-stable repo over the weekend to the > following revision: > > changeset: 9644:07352f119e48 > user: Ali Saidi <[email protected]> > date: Mon Apr 22 13:20:31 2013 -0400 > summary: cpu: fix a switching issue with the o3 cpu. > > If we see any major bugs being reported by users of gem5-stable, I'll try > to see if any patches committed after 07352f119e48 can resolve those and > push them to the stable repo. > > -- > Nilay > > > > On Fri, 24 May 2013, Steve Reinhardt wrote: > > 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<http://[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<http://m5sim.org/mailman/listinfo/gem5-dev> >>>>> >>>>> ______________________________**_________________ >>>> gem5-dev mailing list >>>> [email protected] >>>> http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev> >>>> >>>> >>> ______________________________**_________________ >>> gem5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev> >>> >>> ______________________________**_________________ >> gem5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev> >> >> ______________________________**_________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev> > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
