Re: [gentoo-dev] Developer branches on proj/gentoo

[Alexis Ballier]

On Tue, 11 Aug 2015 16:19:12 +0200
hasufell <hasufell@g.o> wrote:

> On 08/11/2015 04:10 PM, Alexis Ballier wrote:
> > On Tue, 11 Aug 2015 16:01:05 +0200
> > Michał Górny <mgorny@g.o> wrote:
> >
> >> Dnia 2015-08-11, o godz. 15:52:16
> >> Patrice Clement <monsieurp@g.o> 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).

You can merge remote tracking branches just the same you merge
'upstream' branches. You can even rebase them which tends to give a
better history but is harder if you forbid non fast-forward pushes
to gentoo.git. Pull requests are only useful for pre-commit reviews.

> 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.

Branch or remote, this doesn't change anything since no commit to
master will automagically update your branch. The only thing you're
achieving is a fixed gentoo-x86 tree snapshot + an overlay in the same
repo, which you could already do anyway.