Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)

[Clark G. <cga...@vt...>]

I agree with freeze. I suggest that if Eric is willing to perform the final
production migration then he should control that timing (else Mojca,
probably best for you to take the helm?) We may have a few days where the
change is happening, etc that we're frozen (could be just one day, but
giving a little buffer).

After the migration I'll plan to grab a final CVS copy to put into
historical.

Yes one of the really great things about git/if is that repo clone is a
first class citizen, so we can (indeed *will*) have several places the repo
resides. So yes the conversion could happen anywhere. Similarly, merge is
not nearly the horror you would probably associate it with if you've ever
done it with CVS or svn; I still feel my stomach knot up thinking of the
pain unborking a CVS repo following a merge attempt gone bad many years ago.

I'm a little concerned with the longevity of SourceForge, but from our
original discussion of the matter I'll recall the critical decision rule:
support what Ethan wants to work with. :-) Certainly keeping the
environment on SF is the easiest option for me.

[Btw Eric: I *loved* your article on heirloom software and ADVENT last
month in Linux Journal! Thanks for that.]

Regards
Clark

--
Clark Gaylord
cga...@vt...
... Autocorrect may have improved this message
    Brevity should not be interpreted as curtness ...

On Oct 10, 2017 23:57, "sfeam" <sf...@us...> wrote:

> On Monday, 09 October 2017 21:54:42 Hans-Bernhard Bröker wrote:
> >
> > ESR's tool, cvs-fast-import, which "man git-cvsimport" itself recommends
> > to be used instead, shows none of those messages, so I believe that
> > these can be fixed by a change towards cvs-fast-import.
> >
> > I've tried out reposurgen on our repository (with the "faq" module
> > removed), and it seems to work almost perfectly.  "make allcompare"
> > showed nothing missing from the git version.  The original import
> > pseudo-branch GNUPLOT_BETA is, correctly, dropped, all other tags and
> > branch tips compare equal, and .cvsignore files are also taken care of.
> >
> > All in all, I'm quite impressed by this tool.
>
> It looks to me that there is general consensus that
>
> - we should move to git,
>
> - that Eric Raymond's toolset is the best way to do that, and that
>
> - if Eric himself is willing to guide the conversion it has the greatest
> chance of success.
>
> So let's do that.
>
> There is no obvious consensus on where the repository should live.
> I'm going to step in and vote to stay with SourceForge for now
> because I know how to manage their infrastructure for issue trackers and
> putting out a release.
>
> Eric - several people responded with bits and pieces of meta-info that
> you asked for.   Do you have everything you need?
>
> Do I understand correctly that the git repository can be created
> initially anywhere that you find convenient  and then replicated to
> SourceForge afterwards?  If not then maybe we do need additional
> discussion about where to do this.
>
> Should we set a freeze date for the existing CVS source [*]?
> Anything else that needs to be done in preparation?
>
>         Ethan
>
>
> [*] freeze concerns -
>
> 5.2:  I want to package up the current 5.2 branch as an incremental
> release, just so that's out of the way and there is no time pressure after
> the conversion while we deal with any cleanup or fallout.  That takes
> very little time, but I need to know when to do it.
>
> 5.3:  So far as I know this is as good a time as any to freeze.
> The current build is usable as it stands.
>
> Older branches:  There should not be any activity there anyhow.
>
>