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

[Alexis Ballier]

On Tue, 11 Aug 2015 11:51:14 -0400
Ian Stakenvicius <axs@g.o> wrote:

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


I'm glad this wasn't done that way actually. When subslots appeared,
there was a serious tendency to use them in a fashion that caused
useless rebuilds most of the time. With time, and discussions on some
specific cases, saner practices were adopted.


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

Sorry, but no. There was an order in which you could do it, but that's
all.

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

We split up the huge task into small and manageable ones, yes. I see it
as a clear benefit and I'd even say this is one of the major reasons
multilib-portage didn't make it. This also allowed to iteratively
improve the multilib approach with the experience gained from
converting small parts while getting feedback from those interested.

I don't know what conflicts you're talking about, but I haven't
seen any that was not due to a poor conversion.

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

You seem to like pull requests and pre-commit reviews :)
I believe it is optimistic to say that because there is a branch in
gentoo.git then suddenly a lot of people will use this outdated branch
to test the feature.

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

yes; or discussions :)