| 1 |
On 10:46 Thu 06 Nov , Mike Auty wrote: |
| 2 |
> Donnie Berkholz wrote: |
| 3 |
> > <http://dev.gentoo.org/~dberkholz/git/git_conversion.txt>. |
| 4 |
> |
| 5 |
> Ah cool, thanks for that Donnie. 5:) I agree with most parts (save |
| 6 |
> loading the final Options sections with two "Flat tree, 1 repo/package" |
| 7 |
> entries)... 5:P |
| 8 |
|
| 9 |
Fixed that, thanks. |
| 10 |
|
| 11 |
> Given that branching on a repo/tree will let people (by which I assume |
| 12 |
> we both mean developers?) |
| 13 |
|
| 14 |
I am explicitly trying to enable users (not just developers) to more |
| 15 |
easily contribute, maintain, and share their own versions of packages. |
| 16 |
|
| 17 |
> fork off an individual package and then merge it back into the tree |
| 18 |
> with history, this doesn't seem to directly be a pro of 1 |
| 19 |
> repo/package. |
| 20 |
|
| 21 |
It does if you're Joe User (or Joe Proxy-Maintainer) and you don't want |
| 22 |
a 1G+ git clone of the whole tree so you can developer 1 package for |
| 23 |
your local repo. |
| 24 |
|
| 25 |
> Also, it's possible to fork off an individual package and share it |
| 26 |
> without uploading the whole repository by creating a patchset from the |
| 27 |
> branch, which I believe is how several kernel devs work. |
| 28 |
|
| 29 |
Patchsets suck because you can't just grab a repo and emerge what's in |
| 30 |
it. That's the type of usability we want. |
| 31 |
|
| 32 |
> Another available option would be "Current tree, 1 repo/category". It |
| 33 |
> would support some compression of duplicate ebuilds, would make package |
| 34 |
> renames simpler for non-category changes (are there any statistics on |
| 35 |
> whether moves are more often cross category?). |
| 36 |
|
| 37 |
Why don't you check that by running a few commands on profiles/updates/? |
| 38 |
|
| 39 |
> Having said that, there'd also be many of the cons of the "1 |
| 40 |
> repo/package" method (duplication of history during cross-category |
| 41 |
> moves, time for development, complexity of deployment, shared |
| 42 |
> directory problems, etc). |
| 43 |
|
| 44 |
Yeah, you tend to get the worst of both worlds here without the full |
| 45 |
benefits of either. If we wanted to split the tree up at this |
| 46 |
intermediate level, we'd probably rather split it into multiple, mainly |
| 47 |
independent dependency trees (e.g. kde, gnome, web-server, system). But |
| 48 |
for that, we'd likely want some way of specifying repository names in |
| 49 |
dependencies. |
| 50 |
|
| 51 |
> I was also wondering what people's thoughts were on branching? Drobbins |
| 52 |
> appears to be using branching as a keywording method in Funtoo (mainline |
| 53 |
> for the main tree, another branch tracking the mainline for the Funtoo |
| 54 |
> experimental ebuilds). I again imagine cons will outway pros |
| 55 |
> (especially given we already have a solid stable understood process for |
| 56 |
> keywording), but has this been considered? Perhaps an rsyncable branch |
| 57 |
> for each arch, with the arch branches tracking mainline? This would let |
| 58 |
> us prevent non ATs from being able to commit to stable trees. The |
| 59 |
> ebuild simply gets written into the mainline (no KEYWORDS or anything), |
| 60 |
> ATs then pull the ebuild and associated files into the stable/unstable |
| 61 |
> branches as needed, and then even if changes are made to the original |
| 62 |
> ebuild later, they'd have to be explicitly pulled to make it back to |
| 63 |
> stable (and thus offer the chance of another pair of eyes). Downsides |
| 64 |
> are, security fixes would require someone to check-in the fix to each |
| 65 |
> arch (costing time and effort). Thoughts? |
| 66 |
|
| 67 |
The 10-way forking here on per-arch stable branches would make |
| 68 |
maintenance ridiculous, even if all you have to do is run `git |
| 69 |
cherry-pick`. |
| 70 |
|
| 71 |
Doing this approach right, IMO, means treating an ebuild as stable when |
| 72 |
_any_ of its arches is stable (which I think should be done anyway). How |
| 73 |
I'd do it is that an ebuild in the ~arch tree gets pulled to the stable |
| 74 |
tree (there'd only be 1, shared by all arches) by an arch maintainer and |
| 75 |
_deleted_ from the ~arch tree. Once it hits the stable tree, only arch |
| 76 |
maintainers touch it from that point on. Package maintainers only work |
| 77 |
in the ~arch tree. |
| 78 |
|
| 79 |
Doing it this way avoids the real annoyance of pulling across changes to |
| 80 |
"stable" ebuilds constantly because they aren't actually stable at all, |
| 81 |
they're still under development by the package maintainer. |
| 82 |
|
| 83 |
-- |
| 84 |
Thanks, |
| 85 |
Donnie |
| 86 |
|
| 87 |
Donnie Berkholz |
| 88 |
Developer, Gentoo Linux |
| 89 |
Blog: http://dberkholz.wordpress.com |
Archives