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.
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.
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.
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).
//Andreas
[1] http://www.ohloh.net/repositories/compare
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
