Re: git status update?

[Owen Taylor <otaylor redhat com>]

On Fri, 2009-02-27 at 05:20 +0100, Vincent Untz wrote:
> Le jeudi 26 février 2009, à 14:22 -0500, Kristian Høgsberg a écrit :
> > I think we're all set to press the big button after the release goes
> > out, and in the meantime we can move over individual repos not part the
> > GNOME release over if people want. Is there anything specific you want
> > an update on?
> 
> I chatted briefly with Owen a few hours ago. I was thinking there'd be
> a status update sent on the list while he was thinking that I was
> looking at http://live.gnome.org/GitMigration. Small misunderstanding :-)
> 
> So let me take the wiki page and based on this, let's try to see what's
> not ready. I'm assuming we don't need anything that's not mentioned on
> the wiki page, which might or might not be true -- we'll have to check
> this with the whole community before committing to a date for a
> migration.
> 
>  + data integrity: what was verified? Reading the threads here, I got
>    the feeling that a few modules were checked, and then some
>    maintainers checked their modules. But are we 100% confident
>    everything is fine?
>    [blocker]

I'll see if I can get krh to summarize the situation here. One thing
that he pointed out is that it isn't a disaster if some problem shows up
later - we aren't throwing away the svn and cvs data - but certainly the
less we need to go back up and fix later the better.

>  + server usage: has this been evaluated? Is it okay?
>    [not blocker, unless we discover it's really bad]

There really hasn't been any sign of issues, and nobody I talked to
(freedesktop.org in particular) found git serving to be a big deal, but
it's sort of hard to evaluate until we go live.

My backup plan here is if we have problems, I shut down online.gnome.org
until something better is figured out. Without online.gnome.org,
git.gnome.org will have a beefy physical machine pretty much all to
itself.

>  + pre-commit checks: are they implemented?
>    [I'd consider this a blocker, but this is debatable]

Not implemented yet. Now that I got commit emails I'm happy with, I'll
turn to this (and the simpler post-commit hooks like website rebuilds.)

>  + jhbuild: see Fred's mail
>    [potentially blocker if updating a branch is not always working:
>     http://bugzilla.gnome.org/show_bug.cgi?id=549704]

Things have changed underneath that bug report quite a bit over time -
the current state is a lot more satisfactory than what marcopg
originally reported. Not a blocker.

>  + build bot: any news?
>    [blocker: it was hard to start getting the build brigade running.
>     IMHO, it's not an option to lose this]

If there aren't any other necessary elements other than commit mail
parsing, we should be in a pretty good state here.

>  + translators: I think it's more or less fine for documentation. It'd
>    certainly be nice to be able to commit from l10n.gnome.org, though.
>    Is l10n.gnome.org ready for a switch?

The relevant post-commit script doesn't look hard to replicate, even if
the original is written in awk. I don't know what changes would have to
be made to l10n.gnome.org internally to pull from git. (Having it commit
changes is definitely not a blocker since we don't have that for svn.)

>    (I would still think that it'd be nice to have a very limited script
>     that can only do checkout/update/commit for translators, so they
>     don't have to struggle with the git ui, but well, that's just my
>     opinion)
>    [not blocker, unless l10n.gnome.org gets broken]

Alternate command line frontends just seem confusing to me. Improvement
here to me is getting translators away from the command line, whether
it's commits from l10n.gnome.org, transfix, pootle, or whatever.

>  + library.gnome.org: does it need something?
>    (not mentioned on the wiki, but just thought about it)
>    [not blocker: most docs come from tarballs]

No idea.

>  + svn externals: is there a resolution?
>    [blocker: we have modules using this]

The basic answer may have to be that module maintainers have to figure
out for themselves what they want to do. But having a complete list of
where they are being used would definitely be useful. (And something I'd
really appreciate help with..)

>  + commit hooks: are all hooks ported?
>    [potentially blocker: depends on the hooks]

The hooks are discussed elsewhere in this mail.

>  + web front-end: could be improved a bit, but I guess it's mostly fine.
>    [not blocker]

If there are improvements to be made, you are going to have to let us
know what they are :-). (Lars has been extremely responsive upstream.)

>  + how to create a new repo?
>    [not blocker]

Should be a few hours of work. I'll also put this on my list.

>  + migration of docs: we have quite a lot of docs using svn. Eg, if all
>    the stuff under http://live.gnome.org/MaintainersCorner is not ready
>    to be migrated, that's bad.
>    [nearly blocker]
> 
>  + gitorious: has this been evaluated? Can it be set up?
>    [not blocker]

No evaluation yet. But not a blocker.

- Owen