Gentoo Archives: gentoo-scm

From: Alec Warner <antarus@g.o>
To: Mike Auty <ikelos@g.o>
Cc: gentoo-scm@l.g.o
Subject: Re: [gentoo-scm] Help?
Date: Thu, 06 Nov 2008 16:03:05
In Reply to: Re: [gentoo-scm] Help? by Mike Auty
On Thu, Nov 6, 2008 at 2:46 AM, Mike Auty <ikelos@g.o> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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 > > 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----- > >


Subject Author
Re: [gentoo-scm] Help? Christian Faulhammer <opfer@g.o>
Re: [gentoo-scm] Help? Mike Auty <ikelos@g.o>