On 10:46 Thu 06 Nov , Mike Auty wrote:
> Donnie Berkholz wrote:
> > <http://dev.gentoo.org/~dberkholz/git/git_conversion.txt>.
>
> 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: http://dberkholz.wordpress.com
|
