Re: [gentoo-scm] Re: My masterplan for git migration (+ looking for infra to test it)

[Brian Harring]

Folks, pardon the earlier empty reply.  Bit of a fat fingered fuck up on my
part, sorry for that.  Responses inline meanwhile.

On Sun, Sep 14, 2014 at 10:33 AM, Rich Freeman <rich0@g.o> wrote:

> On Sun, Sep 14, 2014 at 8:03 AM, Michał Górny <mgorny@g.o> wrote:
> >
> > I'm quite tired of promises and all that perfectionist non-sense which
> > locks us up with CVS for next 10 years of bikeshed.
>
> While I tend to agree with the sentiment, I don't think you're
> actually targeting the problems that aren't already solved here.
>

Fully agreed; additionally there is an annoying ignorance of the full body
of work folks have done over said years- thin manifests/md5 cache are
simple examples, but there is a lot of work that was done to even make it
*possible* to run from a git repository sanely.


> Of course, that assumes infra is
> > going to cooperate quickly or someone else is willing to provide the
> > infra for it.
>
> The infra components to a git infrastructure are one of the main
> blockers at this point.  I don't really see cooperation as the issue -
> just lack of manpower or interest.
>

I can't speak for current gentoo infra, but it'd help to think through
exactly who will have RO access to the git repo.

Trying to have the entire gentoo userbase accessing the repo via git is
going to be resource intensive- if you're intending that, well, start
donating frankly.

If however you're angling for just devs having git access, and utilizing
the existing rsync mirror, that should be a helluva lot more doable (even
with shitty hardware).

My point there is you probably need to be specific, rather than
vague/bitchy.  It'll avoid the bikeshed, among other things.


> 1. send announcement to devs to explain how to use git,
>
> This is one of the blockers.  We haven't actually decided how we want
> to use git.
>
> Sure, everybody knows how to use git.  The problem is that there are a
> dozen different ways we COULD use git, and nobody has picked the ONE
> way we WILL use it.
>
> This isn't as trivial as you might think.  We have a fairly high
> commit rate and with a single repository that means that in-between a
> pull-merge/rebase-push there is a decent chance of another commit that
> will make the resulting push a non-fast-forward.
>
> People love to point out linux and its insane commit rate.  The thing
> is, the mainline git repo with all those commits has exactly one
> committer - Linus himself.  They don't have one big repo with one
> master branch that everybody pushes to.  At least, that is my
> understanding (and there are certainly others here who are more
> involved with kernel development).
>

To be frank, I think you're seriously overthinking it and worrying about a
nonissue.  Worrying about this while ignoring security enhancements like
requiring signed commits on push is a bit weird to me.

I think prior to arguing this point, folks should take a look at the
chromium-os commit rates and approach.  Gentoo's commit rate will be in the
same rough range- the difference for cros is purely that it was a gated
commit model where pushes didn't land in trunk till they'd had basically
validation- after that validation they were automatically merged in.  If
gentoo really hits that level of churn, that model would work (and have
additional benefits).

Do some research and look at what came before; worst case, just use a
simple model and sort any workflow inefficiencies *after* they come up.


>
> > 2. lock CVS out to read-only,
> >
> > 3. create all the git repos, get hooks rolling,
>

The git -> rsync mirror generation will have to be finished for this-
specifically, converting thin manifests to thick manifests, resigning as
needed.  I believe zmedico did some work on that before moving on, but
others more in the know would have to address that.

ChangeLog generation also would be a nice to have there, and quick to
integrate.

One additional point no one has mentioned; when cutting over to git,
afterwards someone will need to go through and rip out all of the cvs $Id
style tags that exist in the tree- depending on how folks are doing the
conversion, it might be worth just jamming that in right off the bat rather
than trying to clean the tree afterwards.


Actually doing the conversion is basically a solved problem.  If this
> were actually the blocker I'd be all for just sticking the history in
> a different repo and starting from scratch with a new one.
>

Just reiterating; this is a solved problem, and has been for ~2 years.

If somebody can come up with a set of hooks/scripts that will create
> the various trees and the only thing that is left is to get infra to
> host them, I think we can make real progress.  I don't think this is
> something that needs to take a long time.  The pieces are mostly there
> - they just have to be assembled.
>

Frankly, I think Mgorny volunteered himself w/ his earlier "it's been 10
years and y'all haven't done anythign" claim.

~ferringb, who was enjoying his retirement very much thank you