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