Thank you all for your comments on this. In regards to the master/develop branch idea, I'm a big advocate of Jason's "make the most common use the easiest" philosophy. I think he did a good job of describing why this is important. We use the git repo as our primarily way of distributing gem5, and, as such, I believe the default behaviour should be that when a user clones the repo, they are getting the latest stable release to build on top of. I strongly suspect users will disproportionately use whatever `git clone` gives them rather than move between branches or tags in order to get specific, stable releases. If most users end up working on the very latest "unstable" development version then our release system becomes pointless. I realize as everyone on this list is a gem5 contributor, there is a preference for the development branch to be default, but I'd hope we are in the minority of people who actually use gem5. My vote therefore still goes to having two branches: the master/"release" branch and the "develop" branch for day-to-day development. Hotfixes would be created on a separate branch and merged into both upon completion.
Regarding feature branching --- My intention with this part of the proposal was not for feature branches to be the default manner in which people commit to gem5 (as they would be if we were to implement the GitFlow model in full), I consider them something we should allow, in some form, to improve the development process in certain circumstances, but that they should be a rather rare thing. For example, a new component may need several months of development work, consisting of many commits. Developers, at present, have two options: either A) gradually incorporate commits over the months on the master branch, or B) push all the commits to the master branch in one go. I don't think either are ideal solutions. A dedicated feature branch would quarantine these changes while in active development, to be merged at a later date. A second circumstance that could arise is when we wish to postpone the incorporation of a feature. A change that requires an API alteration, for example, should be held-off until we are ready to deploy a major release. Isolating such a change in a feature branch, to be merged later, may be necessary. This all being said, I acknowledge there is a risk in code getting lost indefinitely, or for long periods of time, in feature branches, and our repo getting messy as a result. After some discussion with Jason, I believe the best of both worlds can be achieved if we make feature branches "by request" --- anyone wanting to create a feature branch would need to ask a maintainer (or a PCM) to create one for them. Whether or not a feature branch is to be created would be decided upon on a case-by-case basis. I hope no one feels like I'm dictating anything here. I'm writing this primarily to prompt more discussion, so please feel free to counter any of my points or suggest alternatives. Simple messages of support, as well as criticism, would also be appreciated to help us get a feel for what is, or what is not, proving popular with the community. Kind regards, Bobby -- Dr. Bobby R. Bruce Room 2235, Kemper Hall, UC Davis Davis, CA, 95616 On Wed, Nov 27, 2019 at 4:49 PM Gabe Black <[email protected]> wrote: > The idea of feature branches makes me very nervous. It sounds like a dark > corner for a large body of code to grow in, and then once it pops back into > the light there may be very ingrained and difficult to fix problems which > either have to be ignored or fixed. A long standing branch may also be very > hard to reconcile with ToT, and it may be very tempting to just let it die > rather than try to jump that energy barrier and get it back into mainline. > > This would basically be sanctifying the practice of perma-forking gem5, > which unfortunately happens anyway now and then. There have been a number > of times on the mailing list someone says something along the lines of "I > downloaded special version of gem5 foo from some github" and it turns out > it's X years old with a bunch of old and new bugs, nobody knows how it > works, etc. Let's not encourage that :-). > > Gabe > > On Wed, Nov 27, 2019 at 9:17 AM Vince Harron <[email protected]> wrote: > > > I agree with Ciro that the de facto standard used by most projects is > that > > mainline development should happen in master and releases should be new > > branches created off of master. > > > > You could also create a branch “stable” or “latest” that gets updated to > > the latest release. > > > > The default download instructions could say something like > > > > git clone <url> —branch stable > > > > > > On Wed, Nov 27, 2019 at 8:54 AM Jason Lowe-Power <[email protected]> > > wrote: > > > > > 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 <[email protected]> > > > 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 <[email protected]> on behalf of Bobby Bruce > < > > > > [email protected]> > > > > Sent: Wednesday, November 27, 2019 12:10 AM > > > > To: [email protected] <[email protected]> > > > > 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 > > > > [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 > > > > -- > > > > Vince Harron | Engineering Manager | [email protected] | > 858-442-0868 > > <(858)%20442-0868> > > _______________________________________________ > > 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
