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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 11/08/15 11:21 AM, Alexis Ballier wrote:
> On Tue, 11 Aug 2015 11:11:43 -0400 Ian Stakenvicius
> <axs@g.o> 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
>>> <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
>> 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 :)

Not EAPI bumps, but implementation of major new features as a result
of the new EAPI.  Most EAPI changes generally are beneficial to
particular ebuilds, but some (such as slot-operators and subslots)
really needed to be implemented across a great many packages (and
eclasses too at times).  We did it with overlays and patches via
b.g.o and slowly things migrated, but I think it would have gone a
lot faster if all developers had quick and easy access to a branch.

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

But they don't just touch one package -- you pretty much needed to
do a full deptree at a time.  We worked around it with a rather
messy 'delete all files in emul-* that collide with the
multilib-built packages currently available' plus a convoluted set
of ||() deps wrapping each emul and the individual alternative
atoms.  And even then it was still a mess to try and actually use it
on end-user systems due to various conflicts.

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

This makes sense, yes; the merge back to the main tree could very
well be more difficult than it's worth, however if the branch is
available to all, then the migration into the main tree could be
done piecemeal in batches too rather than in one huge swash.

The point is, I think it'd be easier and faster to implement these
major treewide projects (and easier to verify too) if the work could
be done in a branch available to all, rather than in what would
effectively be an overlay someplace external.How we manage it
effectively, I can't say one way or the other but likely this is
something that we will need to learn from experience as much as
decree policy for.




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlXKGfIACgkQAJxUfCtlWe11XgD/SvvIb9pcZ/k2WRH5OsrKG2G4
0uYC0godRRVytY7s78MA/0dMKUqAlVmqF/HntzPJYoLAqQxGCsrNassDB1iLBV6p
=/msL
-----END PGP SIGNATURE-----