Gentoo Archives: gentoo-scm

From: Mike Auty <ikelos@g.o>
To: Donnie Berkholz <dberkholz@g.o>
Cc: gentoo-scm@l.g.o
Subject: Re: [gentoo-scm] Status of the project?
Date: Sat, 24 Jan 2009 01:39:48
In Reply to: Re: [gentoo-scm] Status of the project? by Donnie Berkholz
Hash: SHA1

Donnie Berkholz wrote:
> And the plan ...
> Daniel isn't pushing much on our end, unless if by pushing you mean > doing things that won't be suitable for us because last I heard, he's > dropping all history from the Funtoo tree.
Oh, I hadn't realized he was doing that (it seems a little pointless, if he's still syncing up the main tree every day), although I guess it may be for size limits?
> 1. Decide whether the existing tree layout is suitable for and best in a > git world. If not, what is? I have done some thinking about this at > <>.
This seems to be the same place we were back in November last year. Is this something we should ask the council about, or continue discussing here? There seem to be two front runners, 1 repo/package and 1 repo/tree. The pros and cons are as set out in your file (the flat tree option pros don't seem to outweigh the cons, so I haven't really considered that). I'm still not convinced that splitting everything into 13000+ repos will be easily managable, but I'm open to being convinced. I'd be interested in walking through a user branching an ebuild and giving it to others and it would be good to flesh out exactly how you imagined it working since it raises a lot of questions. * Would rsync still exist, or would everybody use git as their push/pull tree mechanism? * Would user generated ebuilds be integrated into the local git portage tree, or treated as an overlay? * Would this make the existing overlay mechanism redundant? How would it affect the signing gleps? * Would a commit id be enough to easily identify whether an ebuild came from an official repo or a user generated repo? * How would we ensure that the various packages can't be checked out to different times (one package from 6 months ago, another package from yesterday and dependencies between them) or does that not even matter? I think most of these have a solution, but it depends on how you saw it working... For the 1 repo/tree, I had envisaged using git as the transport for all trees, and rsync being ditched. Unfortunately I'm not sure that'll be feasible, since we've now seen the size of a full tree with complete history (1Gb vs 100Mb), and the history's mostly irrelevant for the average user. Having the option to do either is nice (much like using CVS for the primary tree), but I don't think it'll ever be the default. As such from a user perspective, everything stays much the same (the rsync mirrors can merge the stable/unstable git trees if we go that way, although there'll be some manifest jiggery-pokery that might affect signing, so this'd need further thought) and the only bit that'll really change is that perhaps the Changelogs are finally autogenerated rather than being added by the developer.
> 2. Decide whether the existing development model is suitable for and > best in a git world. If not, what is? I have done some thinking about > this at <>.
This looks good to me, I'm particularly keen on the "Gentoo taking over the world" bit... 5;P
> 3. Switch to the best layout and development model. > > Issue 3 is the easy one.
Hehehe, don't worry, I won't quote you on that in the future... 5;) Mike 5:) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkl6cV8ACgkQu7rWomwgFXrVQwCdE8wFMgEg+FRpDf3COq/FYkcT 4koAn3vgT/16trq1hRT5tqIGIvSYSGar =Rhzn -----END PGP SIGNATURE-----


Subject Author
Re: [gentoo-scm] Status of the project? "Robin H. Johnson" <robbat2@g.o>