| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Donnie Berkholz wrote: |
| 5 |
> <http://dev.gentoo.org/~dberkholz/git/git_conversion.txt>. |
| 6 |
|
| 7 |
Ah cool, thanks for that Donnie. 5:) I agree with most parts (save |
| 8 |
loading the final Options sections with two "Flat tree, 1 repo/package" |
| 9 |
entries)... 5:P |
| 10 |
|
| 11 |
Given that branching on a repo/tree will let people (by which I assume |
| 12 |
we both mean developers?) fork off an individual package and then merge |
| 13 |
it back into the tree with history, this doesn't seem to directly be a |
| 14 |
pro of 1 repo/package. Also, it's possible to fork off an individual |
| 15 |
package and share it without uploading the whole repository by creating |
| 16 |
a patchset from the branch, which I believe is how several kernel devs |
| 17 |
work. I can see the argument more for wanting to automatically post a |
| 18 |
URL that will always be up-to-date though. |
| 19 |
|
| 20 |
Another available option would be "Current tree, 1 repo/category". It |
| 21 |
would support some compression of duplicate ebuilds, would make package |
| 22 |
renames simpler for non-category changes (are there any statistics on |
| 23 |
whether moves are more often cross category?). Having said that, |
| 24 |
there'd also be many of the cons of the "1 repo/package" method |
| 25 |
(duplication of history during cross-category moves, time for |
| 26 |
development, complexity of deployment, shared directory problems, etc). |
| 27 |
|
| 28 |
I was also wondering what people's thoughts were on branching? Drobbins |
| 29 |
appears to be using branching as a keywording method in Funtoo (mainline |
| 30 |
for the main tree, another branch tracking the mainline for the Funtoo |
| 31 |
experimental ebuilds). I again imagine cons will outway pros |
| 32 |
(especially given we already have a solid stable understood process for |
| 33 |
keywording), but has this been considered? Perhaps an rsyncable branch |
| 34 |
for each arch, with the arch branches tracking mainline? This would let |
| 35 |
us prevent non ATs from being able to commit to stable trees. The |
| 36 |
ebuild simply gets written into the mainline (no KEYWORDS or anything), |
| 37 |
ATs then pull the ebuild and associated files into the stable/unstable |
| 38 |
branches as needed, and then even if changes are made to the original |
| 39 |
ebuild later, they'd have to be explicitly pulled to make it back to |
| 40 |
stable (and thus offer the chance of another pair of eyes). Downsides |
| 41 |
are, security fixes would require someone to check-in the fix to each |
| 42 |
arch (costing time and effort). Thoughts? |
| 43 |
|
| 44 |
Mike 5:) |
| 45 |
-----BEGIN PGP SIGNATURE----- |
| 46 |
Version: GnuPG v2.0.9 (GNU/Linux) |
| 47 |
|
| 48 |
iEYEARECAAYFAkkSyukACgkQu7rWomwgFXp8nQCgmkUNzd049LuwN9x8BThHAJpN |
| 49 |
p7MAnRGG7pOWiud3D8LYzsrXBp6+xOCj |
| 50 |
=Blxs |
| 51 |
-----END PGP SIGNATURE----- |
Archives