Thanks for the input Ciro! My pushback here is that most people who use gem5 will be making modifications to it (at least for the foreseeable future). I don't think we want to common use case to be 1) Download a tarball, 2) make local modifications to the source. I think we want people to 1) clone a "stable" gem5, 2) make modifications to the stable branch for their research *in git*.
My experience with architecture grad students and researchers is that if you don't force them to use things like git most of them won't. One of my (personal) goals is to make it easy/default to use gem5 "the right way". In fact, I almost don't want to provide tarballs at all. Unless we can provide pre-build gem5 binaries, I don't think it makes sense to provide tarballs. I don't think prebuilt binaries make sense for the research use case of gem5 since almost all research will require extending gem5 and there's no way to dynamically load in new modules (though we should support this in the future!). For teaching with gem5 prebuilt binaries could make sense, but I think we'll hold off on that for now, TBH. I think this comes down to "make the common case fast". I believe the common case is researchers who want to make minor changes to gem5 (e.g., add a new SimObject or modify the cache protocol) and run experiments for their research. Developing gem5 for the community (using the development branch) is actually the uncommon case. BTW, I agree with you that we should try to follow whatever practices are most popular when it makes sense. However, in many ways gem5 is a unique project, so following others doesn't always make sense :). I'm open to discussion on this. Thoughts? Cheers, Jason On Wed, Nov 27, 2019 at 12:01 AM Ciro Santilli <ciro.santi...@arm.com> wrote: > Thanks Bobby for pushing this forward, having releases would be a good > thing for gem5. > > I would recommend against having both master and develop branch though, > because in the large majority of projects out there, master == the latest > version, so I'm always confused when I have to switch to develop, specially > if it isn't the default HEAD (is is however possible to set the default > branch to develop as shown as: > https://gerrit-review.googlesource.com/Documentation/project-configuration.html#default-branch > ) > > This is even more important if we start having prebuilt releases or tgzs > with source (which are smaller than full repo) for the tags, at which point > basically everyone who clones wants the latest. > > I would instead recommend: > > - master: latest version > - v2019: a tag. The latest one can be easily found with: > https://stackoverflow.com/questions/1404796/how-to-get-the-latest-tag-name-in-current-branch-in-git > - 2019 or b2019: branch created at the same time as v2019 to which > backports are applied, and to which v2019.0.1 tags can also be optionally > applied > > > ________________________________ > From: gem5-dev <gem5-dev-boun...@gem5.org> on behalf of Bobby Bruce < > bbr...@ucdavis.edu> > Sent: Wednesday, November 27, 2019 12:10 AM > To: gem5-dev@gem5.org <gem5-dev@gem5.org> > Subject: [gem5-dev] gem5 19.0.0 : New git branching proposal > > Dear all, > > As you know, at the end of this quarter we will be releasing gem5-19, the > first official release of gem5. As part of this release we'd like to change > our git branching structure. Therefore, I'm writing to ask for feedback on > what we have planned and whether it can be improved upon. > > We'd like to have a git repo structure similar to that used in gitflow > development: https://nvie.com/posts/a-successful-git-branching-model . > I've > seen this model work well before, as it has some worthwhile abstractors for > public, open source git projects with regular releases. What I'd like to > incorporate from this model is the following: > > - Two permanent branches: master and develop. > - "develop" would function as master does now. This would be the main point > in which changes are applied between gem5 releases. > - Upon a new release of gem5, the develop branch would be merged into > master and a new git tag added to master indicating the release version. > Ergo, the master branch would always contain the latest release of gem5. > - If a quick hotfix is needed, a new "hotfix" branch would be created and > merged into both the develop and master branches upon completion. This > would also require a new tag on the master branch. (I suggest using the > standard "Version [Major].[Minor].[Hotfix]" version numbering system. I.e., > the first version would be V19.0.0, a hotfix to this would make it V19.0.1, > and a minor release would make it V19.1.0). > - The creation of feature branches would be permitted. These branches would > encapsulate the gradual development of large features (i.e., ones carried > out over many commits). When complete a feature branch would be merged into > the develop branch. They'd be no obligation to use feature branches though > we believe they could be of value in certain cases. For example, if a > developer wishes to postpone a developed feature for a given gem5 release > (e.g., something more suited for a major release rather than a minor one), > then they could submit their changes as a feature branch and wait to merge > to the develop branch at a later date. > > I believe this setup would make our development process run smoother and > give gem5 users more stability. Day-to-day development wouldn't change much > as committing to the develop branch would work in the same way as > submitting to master does now. > > If anyone has any thoughts about this, I'd be happy to hear from you. > > Kind regards, > Bobby > -- > Dr. Bobby R. Bruce > Room 2235, > Kemper Hall, UC Davis > Davis, > CA, 95616 > _______________________________________________ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
