On 16 Dec 2019, at 19:50, Jason Lowe-Power wrote:
I think master should be development.
I think gem5 should “”””release”””” once per year (a
release is not what you described the stable branch would be).
I kept thinking ... feel free to ignore my 50 cents below:
(i) I don’t want to fight the rest of the world treating git one way,
where development is master.
(ii) I am still not sure how “stable” will be screwed up 1 or 3
times a year if you “merge” “development” over a “stable”
branch. If “stable” is “master” and the next pull accidentally
ends on top of it it’ll be in conflict hell. Do you plan to point
HEAD to development instead? Your plan very much sounds nice (fast
forward) for the one having no changes in “stable” but horrible for
anyone doing their work there.
(iii) I am still not sure how referencing “one stable branch” can be
named in a paper if you need a git hash or a date as well (sounds like
CVS times). Even if you’d provide tags, any bugfix merges will still
not be the same code. And in the end local modifications will mean it
wasn’t gem5 “stable” but a local tree of a gem5 stable + changes
(which also should be published).
Like many I’ve seen plenty of research projects being done on a
(stale) “stable” branch and once the research was done the work was
forgotten or at best tarballed away or a “dead repo somewhere” and
basically lost. I have seen few people doing their engineering for the
research on development branch and then actually merging to stable and
that’s usually the projects which are in use, cited often, look for
something beyond a paper, .. Strangely this is also how release
engineering usually seems to work.
One will need to branch for once own research anyway, be it from master,
development, or stable. If you work directly on master you simply screw
yourself or you don’t use git.
One will need to be able to diff ones own work to a “parent” in
order to extract changes to be pushed to gem5 for upstreaming. If I
work on a stable branch which gets a major upgrade in between, I need to
solve those changes and conflicts first and then again against
development when porting forward (which usually is a lot harder than
back-porting)?
I think gem5’s interest should be to make research easy and to engage
the community to make their changes upstreamable so that the work is not
lost but integrated and available for many. The big companies named do
a great job of doing this, but how much 3rd party research community
actually comes back into the tree?
If I were to do gem5 research I’d do for 1 project (if you do multiple
in parallel you do more sophisticated naming of multiple branches ;-):
(a) branch development (ideally “master”) -> bz_master & do
continuous changes and pull/merge regularly from upstream.
(b) upstream all changes not needing “confidentiality” until
publication (easy given they are based off the development branch).
(c) pick the latest stable branch (which kind of implies there is a
release structure again of say stable/20200401 or whatever name you give
it.
(d) make a branch if (c) bz_stable_20200401 and backport my changes to
that. This is the branch I might be stuck with for 3-6 years for my
research (think of a PhD lifetime in various parts of the world). In a
real world I’ll probably have a bz_stable_20201001 by the time I
finally get to the point when the 1st bit of engineering is done and I
can write up a first paper. Either a forward port stable->stable or a
backport to a different stable; the first real pain unless you chose
wisely and your development branch basically matches your new stable
branch at that point.
(e) keep the cycle alive with back porting becoming harder and harder as
the years go by.
(f) publish and upstream rest of the changes.
(g) go through the “review process, refine changes, ...”
(h) Say paper 1/2/3. Peer reviewed. Work upstreamed to community,
reviewed. Found mistake from 1st paper during that process, updated the
results since. Being honest ;-)
While your question of “what will be master?” seems important, the
question you are asking is “do we want to be using the SCM system
differently than most of the world raising the bar to entry just an
extra bit?”
If I look up there, I, as a developer and user, have totally different
things to sort out than the default of a branch.
/bz
_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
