Re: [gentoo-scm] Help?

[Alec Warner]

On Thu, Nov 6, 2008 at 2:46 AM, Mike Auty <ikelos@g.o> wrote:
> -----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?

2 commits instead of one sounds silly.

Do we have chronic problems where package maintainers muck with
keywords which then have negative effects?

-Alec

>
> Mike  5:)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
>
> iEYEARECAAYFAkkSyukACgkQu7rWomwgFXp8nQCgmkUNzd049LuwN9x8BThHAJpN
> p7MAnRGG7pOWiud3D8LYzsrXBp6+xOCj
> =Blxs
> -----END PGP SIGNATURE-----
>
>