Thanks Nilay! Ali On Jun 14, 2013, at 5:23 PM, Steve Reinhardt <[email protected]> wrote:
> 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 > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
