On 08/11/2015 04:10 PM, Alexis Ballier wrote: > On Tue, 11 Aug 2015 16:01:05 +0200 > Michał Górny <mgo...@gentoo.org> wrote: > >> Dnia 2015-08-11, o godz. 15:52:16 >> Patrice Clement <monsie...@gentoo.org> napisał(a): >> >>> Hi there >>> >>> According to >>> https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model, >>> "there may be developer-specific, task-specific, project-specific >>> branches etc". As far as I understand, it means I can go and create >>> my own branch on the main repository and push it and it gets spread >>> all over the place. Is that correct? >>> >>> Could someone explain to me the rationale behind this decision? >>> >>> Truth to be told, I kinda dislike the fact any developer can do >>> this. >> >> As long as it's used with caution, I don't see a problem. > > Then we should define 'caution' I think :) > >> Of course it >> would be bad if everyone pushed branches for any minor change. >> However, if there is a long-term work going on a branch, I don't see >> a problem with keeping it public. > > Most, if not all, projects I've seen use forks for this.
Blender does not, afaik. And I've seen a lot of projects doing that. The difference between e.g. "myremote/featurebranch" and "upstream/featurebranch" is just that someone has looked over "upstream/featurebranch" and that it requires pull requests to get stuff in (so the developer work happens in their developer forks, but the results still get into the same upstream branch). That would, for example, make sense for libressl. Since we basically just overwrite a lot of ebuilds to be able to test them with libressl patches. That is currently done with an overlay which always opens up the problem that we lack behind the tree and undesired openssl ebuilds leak in for the user, because of tree-overlay desync.
