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
