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
