On Tue, 11 Aug 2015 11:51:14 -0400 Ian Stakenvicius <a...@gentoo.org> 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 > > <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 :) > > 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 :)
