| 1 |
On Tue, 11 Aug 2015 11:11:43 -0400 |
| 2 |
Ian Stakenvicius <axs@g.o> wrote: |
| 3 |
|
| 4 |
> -----BEGIN PGP SIGNED MESSAGE----- |
| 5 |
> Hash: SHA256 |
| 6 |
> |
| 7 |
> On 11/08/15 10:01 AM, Michał Górny wrote: |
| 8 |
> > Dnia 2015-08-11, o godz. 15:52:16 Patrice Clement |
| 9 |
> > <monsieurp@g.o> napisał(a): |
| 10 |
> > |
| 11 |
> >> Hi there |
| 12 |
> >> |
| 13 |
> >> According to |
| 14 |
> >> https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model, |
| 15 |
> >> |
| 16 |
> >> |
| 17 |
> "there may be developer-specific, task-specific, project-specific |
| 18 |
> branch es |
| 19 |
> >> etc". As far as I understand, it means I can go and create my own |
| 20 |
> >> branch on the main repository and push it and it gets spread all |
| 21 |
> >> over the place. Is that correct? |
| 22 |
> >> |
| 23 |
> >> Could someone explain to me the rationale behind this decision? |
| 24 |
> >> |
| 25 |
> >> Truth to be told, I kinda dislike the fact any developer can do |
| 26 |
> >> this. |
| 27 |
> > |
| 28 |
> > As long as it's used with caution, I don't see a problem. Of course |
| 29 |
> > it would be bad if everyone pushed branches for any minor change. |
| 30 |
> > However, if there is a long-term work going on a branch, I don't |
| 31 |
> > see a problem with keeping it public. |
| 32 |
> > |
| 33 |
> |
| 34 |
> Examples in particular I can think of for something like this being |
| 35 |
> useful would be for, say, major EAPI-bump-related feature |
| 36 |
> implementations (ie, EAPI5 and slot-operators/subslots), or major |
| 37 |
> across-tree impementation changes like what we saw with the |
| 38 |
> multilib-eclass porting. |
| 39 |
> |
| 40 |
> These are large projects touching most if not all ebuilds, that a |
| 41 |
> great many developers would or should be involved in. Something like |
| 42 |
> this could be done in a separately hosted repo instead of in the main |
| 43 |
> gentoo repo, but then all developers would need to subscribe to this |
| 44 |
> other repo, while having it in a branch in the main one i think would |
| 45 |
> make it easier for everyone to get involved once they're ready, and |
| 46 |
> would still allow the changes to stay out of the master branch until |
| 47 |
> the project is ready to launch. |
| 48 |
|
| 49 |
|
| 50 |
For me, this is actually a reason to prohibit it :) |
| 51 |
|
| 52 |
EAPI bumps should be done package by package, not at a major scale: |
| 53 |
otherwise, let's just scrap EAPI entirely and update the API as we see |
| 54 |
fit with p.masked package managers :) |
| 55 |
|
| 56 |
multilib eclasses conversions should also be done one by one to be done |
| 57 |
properly (otherwise using multilib-portage is probably a better idea) |
| 58 |
and each conversion touches one package (two if you count emul-*). |
| 59 |
|
| 60 |
Big changes that that go in feature branches and are merged in one pass |
| 61 |
are, from my experience, way too much prone to errors. Did anyone ever |
| 62 |
try to review a merge commit? |
Archives