On Thu, Nov 6, 2008 at 2:46 AM, Mike Auty <email@example.com> 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?
> Mike 5:)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> -----END PGP SIGNATURE-----