Re: IMPORTANT: It's time to migrate from CVS (your input needed)

On Mon, Oct 16, 2017 at 5:17 AM, Robert Eden <[email protected]> wrote:


Since you asked, here are some random
thoughts.... (some even relevant to the
questions asked).


> I'm not that familiar with github, other than as a repository... should we
> migrate things other than the repository?

I would recommend yes (where possible),
but since the critical step is moving off cvs,
there is the argument that one should not
get distracted on the other points, since they
can be deferred (with some different pain
for contributors and users during the various
transitions).

>     bug tracker

The github bug tracker (issue tracker) is "OK",
but is not exactly full featured (it is not a bugzilla,
or a trac, or a servicenow), but then neither
is the SF bug tracker.  Moving the issue tracker
to gihub would have the advantage of a one-stop
shop for issues and fixes by contributors (easy
to close issues and reference the commit).

I think I would be willing to attempt to do this
migration for the project (it is a one time thing),
but as I recall it required some direct rights on
the SF project (and perhaps the github project).
It has been a very long time since I did this
(and it was a lot of manual work at the time
because the APIs were not yet featured, and
it was a personal repo, so I had all the rights
I needed).

An alternative migration strategy, of course, is
to simply leave the history at sourceforge,
and require all new issues to be at github.

>     release distribution

github has integration apis, but is not (itself)
a CI/CD service (travis ci is a well known choice,
but there are others (many many others)).

I am not familiar with the way that the project
builds a binary release for Windows.  For
things like linux, as long as you tag releases
correctly distro packagers can easily pull (and
rebuild) any release (or master) one wishes
using the clone or download (at a tag)
capability.

For a transition period, it may be possible
to (badly/painfully) export from a git repo
to a local CVS repo, and then some existing
tools in your process might work.  Maybe.  I
would not suggest this being a good long term
strategy.

>     mailing lists

This is one thing that github does not provide
(AFAIK).  However, as SF (IMHO) has clearly
demonstrated that they are not capable of
running such a service reliably today, I
have zero expectation they will be able to
start to do so tomorrow (they have had
years, and have not gotten it right so far).
Yes, this issue is one of my ongoing pet
peeves regarding SF.

However, as there is not one obvious choice,
and it is mostly not linked with repo activity
itself, I would leave this to be the last to migrate
(some of the solutions others tend to use
include google groups or yahoo groups,
although they have their pluses and minues,
and there is freelists (which is free as in beer),
along with the pure mail solutions (such as
mailchimp, helpmonks may be viable))..

>     xmltv.org wiki (currently hosted by me, not SF)

github provides a wiki.  It is a different wiki.  There
is no one right wiki (although many will argue
that their choice is the only right one).  The github
wiki is no where near as flexible as mediawiki
which the project currently uses, but as I
recall, the existing xmltv wiki is not extensive,
so migration is likely possible without too much
effort (there are tools to migrate mediawiki to
the github wiki format).  But markdown is
certainly different than what one might be
used to.  With a github wiki you can either allow
everyone (with a github account) to edit the wiki,
or you can restrict it only to collaborators.  Again,
there is the "one stop shop" advantage to
moving.  [btw, since you mentioned Schedules
Direct, you likely know they use the github
wiki for their json docs; it works "ok"; don't
love it, but I can live with it.]

> Which github plan?   I'm sure Schedules Direct would be willing to cover a
> reasonable subscription.

The "free" plan works OK for true open source repos
with a reasonable number of full committers similar
to what the SF xmltv cvs repo has now (the paid plans
are needed if you want to host private repos, or wish
(need) to add fine grained commit privs such as
(say) Jane can only commit to her particular directory,
and John can only commit to his).  There are (were)
also a few integration APIs that are only available
under the paid plans (which is less important if
one has most of their process in github).



Note that it will be critical that more than one person
have the needed admin knowledge (password, two
factor authenticator key) to the github project (bus's
happen).  Nick will need to share with someone
trustworthy (or at least least untrustworthy?).  Since
this is not a high profile project, setting up two-factor
may be overkill, but two factor may make the need to
share the password less problematic as there were
various recovery methods for forgotten passwords.
I would think that if the agreement is to use the existing
github account this is step 0.

If one has the intention to also move the bug
tracker to github, Step 1 would be to get all contributors
to create a github account (if they do not have one),
and get their SF and github userids posted, as
some of the migration tools attempt to migrate
the issues from SF to github users, and one needs
that mapping (the default without the mapping tends
to be the project, which may end up confusing).



A question not asked recently, but asked previously,
was about individual grabber version numbers.  The
current library depends on the cvs revision values.  This
will need to be well documented to contributors.  I
suspect there is some opportunity to consider handling
this versioning differently, but again, does not need to be
done at migration time.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot