-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Donnie Berkholz wrote:
> And the plan ...

Quite!

> 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 
> <http://dev.gentoo.org/~dberkholz/git/git_conversion.txt>.

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 <http://dev.gentoo.org/~dberkholz/master_plan.txt>.

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-----