Gentoo Archives: gentoo-scm

From: Donnie Berkholz <dberkholz@g.o>
To: Mike Auty <ikelos@g.o>
Cc: gentoo-scm@l.g.o
Subject: Re: [gentoo-scm] Help?
Date: Fri, 07 Nov 2008 01:42:20
Message-Id: 20081107014214.GB29386@comet
In Reply to: Re: [gentoo-scm] Help? by Mike Auty
On 10:46 Thu 06 Nov     , Mike Auty wrote:
> Donnie Berkholz wrote: > > <>. > > Ah cool, thanks for that Donnie. 5:) I agree with most parts (save > loading the final Options sections with two "Flat tree, 1 repo/package" > entries)... 5:P
Fixed that, thanks.
> Given that branching on a repo/tree will let people (by which I assume > we both mean developers?)
I am explicitly trying to enable users (not just developers) to more easily contribute, maintain, and share their own versions of packages.
> fork off an individual package and then merge it back into the tree > with history, this doesn't seem to directly be a pro of 1 > repo/package.
It does if you're Joe User (or Joe Proxy-Maintainer) and you don't want a 1G+ git clone of the whole tree so you can developer 1 package for your local repo.
> Also, it's possible to fork off an individual package and share it > without uploading the whole repository by creating a patchset from the > branch, which I believe is how several kernel devs work.
Patchsets suck because you can't just grab a repo and emerge what's in it. That's the type of usability we want.
> Another available option would be "Current tree, 1 repo/category". It > would support some compression of duplicate ebuilds, would make package > renames simpler for non-category changes (are there any statistics on > whether moves are more often cross category?).
Why don't you check that by running a few commands on profiles/updates/?
> Having said that, there'd also be many of the cons of the "1 > repo/package" method (duplication of history during cross-category > moves, time for development, complexity of deployment, shared > directory problems, etc).
Yeah, you tend to get the worst of both worlds here without the full benefits of either. If we wanted to split the tree up at this intermediate level, we'd probably rather split it into multiple, mainly independent dependency trees (e.g. kde, gnome, web-server, system). But for that, we'd likely want some way of specifying repository names in dependencies.
> I was also wondering what people's thoughts were on branching? Drobbins > appears to be using branching as a keywording method in Funtoo (mainline > for the main tree, another branch tracking the mainline for the Funtoo > experimental ebuilds). I again imagine cons will outway pros > (especially given we already have a solid stable understood process for > keywording), but has this been considered? Perhaps an rsyncable branch > for each arch, with the arch branches tracking mainline? This would let > us prevent non ATs from being able to commit to stable trees. The > ebuild simply gets written into the mainline (no KEYWORDS or anything), > ATs then pull the ebuild and associated files into the stable/unstable > branches as needed, and then even if changes are made to the original > ebuild later, they'd have to be explicitly pulled to make it back to > stable (and thus offer the chance of another pair of eyes). Downsides > are, security fixes would require someone to check-in the fix to each > arch (costing time and effort). Thoughts?
The 10-way forking here on per-arch stable branches would make maintenance ridiculous, even if all you have to do is run `git cherry-pick`. Doing this approach right, IMO, means treating an ebuild as stable when _any_ of its arches is stable (which I think should be done anyway). How I'd do it is that an ebuild in the ~arch tree gets pulled to the stable tree (there'd only be 1, shared by all arches) by an arch maintainer and _deleted_ from the ~arch tree. Once it hits the stable tree, only arch maintainers touch it from that point on. Package maintainers only work in the ~arch tree. Doing it this way avoids the real annoyance of pulling across changes to "stable" ebuilds constantly because they aren't actually stable at all, they're still under development by the package maintainer. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog:


Subject Author
Re: [gentoo-scm] Help? Mike Auty <ikelos@g.o>
Re: [gentoo-scm] Help? "Robin H. Johnson" <robbat2@g.o>
Re: [gentoo-scm] Help? Ryan Hill <dirtyepic@g.o>
Re: [gentoo-scm] Help? Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
Re: [gentoo-scm] Help? Mike Auty <ikelos@g.o>