On Tue, 11 Aug 2015 11:11:43 -0400 Ian Stakenvicius <a...@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 11/08/15 10:01 AM, Michał Górny 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 > branch es > >> 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. 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. > > > > Examples in particular I can think of for something like this being > useful would be for, say, major EAPI-bump-related feature > implementations (ie, EAPI5 and slot-operators/subslots), or major > across-tree impementation changes like what we saw with the > multilib-eclass porting. > > These are large projects touching most if not all ebuilds, that a > great many developers would or should be involved in. Something like > this could be done in a separately hosted repo instead of in the main > gentoo repo, but then all developers would need to subscribe to this > other repo, while having it in a branch in the main one i think would > make it easier for everyone to get involved once they're ready, and > would still allow the changes to stay out of the master branch until > the project is ready to launch. For me, this is actually a reason to prohibit it :) EAPI bumps should be done package by package, not at a major scale: otherwise, let's just scrap EAPI entirely and update the API as we see fit with p.masked package managers :) multilib eclasses conversions should also be done one by one to be done properly (otherwise using multilib-portage is probably a better idea) and each conversion touches one package (two if you count emul-*). Big changes that that go in feature branches and are merged in one pass are, from my experience, way too much prone to errors. Did anyone ever try to review a merge commit?
