[gentoo-project] Re: Call for Council Agenda Items - 14 Oct 2014

[Rich Freeman <rich0@gentoo.org>]

On Tue, Sep 30, 2014 at 10:08 PM, Rich Freeman <rich0@gentoo.org> wrote:
>
> If you'd like to contribute another agenda item, please reply to this email.
>

I'll offer up a further topic for the git migration.

I propose that we're basically ready to go with the git migration.  We
have a proposed workflow, we have a reasonable migration path for
history, and a "perfect" migration process for the current tree, and
we now have back-end scripts for adding metadata, manifests, etc and
creating an rsync tree.

There are open questions around things like news and changelogs
already on the agenda.

I'm not quite sure how to frame the question I'd like the council to
answer, but I'd really like to get this down to, "is anything left or
can we do this already?"

The biggest concerns I see as pending are changelogs which have
already been hashed out, and whether we need a better migration of the
cvs history before we go.  Changelogs have already been hashed out so
I'll summarize where migration of history stands.

Right now the migration process generates a full cvs history in git,
with a number of caveats:
1.  CVS tracks history at the file level, git at the tree level.  The
migration process tries to match up corresponding changes, but this is
far from perfect.  So, many commits will contain non-matching
manifests and files, which means manifests will not pass.  The only
place we can be sure there won't be manifest issues (other than those
already in cvs) is in the final commit, which matches the active tree.

2.  CVS keywords are a mess in general.  There are a bunch of
situations which cause them to not match.  This could be improved, but
I'm really wondering if we should bother.

I'd propose that we really make the requirement be that the final tree
with manifests matches.  We're actually going to ditch the manifests
anyway, and likely even header keywords and changelogs (likely in
later commits).  Many projects have migrated to git without setting a
goal of a perfect history migration, and our heavy use of keywords and
manifests makes our case particularly tricky if we want a "perfect"
migration.

Now that git has the "replace" function I'd suggest that we view the
tree moving forward and the historical tree as separate problems.  We
can migrate the active tree to git and move forward, and then we can
make a pretty useful git migration for those who want to look
backwards.  If anybody wants to further improve the historical tree
they could do so at any time - all the code is open source and we can
make the data available.  However, I just don't know much interest
there really is in a "perfect" historical migration and certainly
there isn't an army of volunteers working to improve cvs2svn/etc.  In
fact, half the issues I do run into involve digging up 10-year-old
mailing list posts since that was when most of the rest of the world
was interested in ditching cvs.

Obviously the actual migration requires some coordination with
infra/etc, but I'd like to shift the bias towards action and ask "why
not now?"  If there are good reasons to wait, let's discuss them,
agree whether they're issues, and then work out a plan to resolve
them.

--
Rich