Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-scm
Navigation:
Lists: gentoo-scm: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: Mike Auty <ikelos@g.o>
From: Donnie Berkholz <dberkholz@g.o>
Subject: Re: Help?
Date: Thu, 6 Nov 2008 17:42:14 -0800
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
Attachment:
pgpZ3zigT27yD.pgp (PGP signature)
Replies:
Re: Help?
-- Mike Auty
Re: Help?
-- Mike Auty
Re: Help?
-- Robin H. Johnson
Re: Help?
-- Ryan Hill
Re: Help?
-- Ciaran McCreesh
References:
Help?
-- Christian Faulhammer
Re: Help?
-- Donnie Berkholz
Re: Help?
-- Alec Warner
Re: Help?
-- Fabian Groffen
Re: Help?
-- Alec Warner
Re: Help?
-- Christian Faulhammer
Re: Help?
-- Mike Auty
Re: Help?
-- Donnie Berkholz
Re: Help?
-- Mike Auty
Navigation:
Lists: gentoo-scm: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Help?
Next by thread:
Re: Help?
Previous by date:
Re: repoman patch for git support (from drobbins)
Next by date:
Re: Help?


Updated Jun 17, 2009

Summary: Archive of the gentoo-scm mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.