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: gentoo-scm@g.o
From: Mike Auty <ikelos@g.o>
Subject: Re: Help?
Date: Thu, 06 Nov 2008 10:46:01 +0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

Given that branching on a repo/tree will let people (by which I assume
we both mean developers?) 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.  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.  I can see the argument more for wanting to automatically post a
URL that will always be up-to-date though.

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

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?

Mike  5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkkSyukACgkQu7rWomwgFXp8nQCgmkUNzd049LuwN9x8BThHAJpN
p7MAnRGG7pOWiud3D8LYzsrXBp6+xOCj
=Blxs
-----END PGP SIGNATURE-----


Replies:
Re: Help?
-- Donnie Berkholz
Re: Help?
-- Alec Warner
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
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: Help?
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.