[Firebird-docs] Consider migrating to GitHub?

[Mark Rotteveel]

Isn't it time to consider migrating the documentation repository from
SourceForge CVS to GitHub?

SourceForge itself considers CVS deprecated, and having the repository
on GitHub might increase visibility and will likely lower the barrier
for contribution.

Mark

[Paul Vinkenoog]

Post by Mark Rotteveel
Isn't it time to consider migrating the documentation repository from
SourceForge CVS to GitHub?
SourceForge itself considers CVS deprecated, and having the repository
on GitHub might increase visibility and will likely lower the barrier
for contribution.

No objections here, but does anybody have any experience with this kind
of migration? (Preferably including history.)

Myself, I'm a basic GIT user and I only use it locally.


Paul Vinkenoog

[Helen Borrie]

Post by Mark Rotteveel
Isn't it time to consider migrating the documentation repository from
SourceForge CVS to GitHub?
SourceForge itself considers CVS deprecated, and having the repository
on GitHub might increase visibility and will likely lower the barrier
for contribution.

Helen Borrie: I don't see how moving the source from one obscure repository to a different obscure repository would heighten visibility or lower any barrier.

If there's a good reason to change, I'd go with it, albeit it currently aint broke so there be nothing to fix.  PaulV has it nicely set up for use by the translators and it is all well documented, enough so that those of us who actually DO stuff regularly, rather than just talk about doing it, have our local setups that are more or less automated. One of us can always step in to assist people who don't want to work with a repository for whatever reason.  I don't see how changing the repository would (or should) alter that. 
My personal experience so far with GitHub is that it is a dog to work with, actually, given that I don't upload or download any programming code, only documentation.  I guess if I had to, I'd find a way to make it useful for me to use.  I just can't think of a good reason right now to spend time and energy on creating a solution to a non-existent problem.

Helen

[Lester Caine]

Post by Mark Rotteveel
Isn't it time to consider migrating the documentation repository from
SourceForge CVS to GitHub?
SourceForge itself considers CVS deprecated, and having the repository
on GitHub might increase visibility and will likely lower the barrier
for contribution.

*Helen Borrie:* I don't see how moving the source from one obscure
repository to a different obscure repository would heighten visibility
or lower any barrier.
If there's a good reason to change, I'd go with it, albeit it currently
aint broke so there be nothing to fix. PaulV has it nicely set up for
use by the translators and it is all well documented, enough so that
those of us who actually DO stuff regularly, rather than just talk about
doing it, have our local setups that are more or less automated. One of
us can always step in to assist people who don't want to work with a
repository for whatever reason. I don't see how changing the repository
would (or should) alter that.
My personal experience so far with GitHub is that it is a dog to work
with, actually, given that I don't upload or download any programming
code, only documentation. I guess if I had to, I'd find a way to make
it useful for me to use. I just can't think of a good reason right now
to spend time and energy on creating a solution to a non-existent problem.

CVS still has a number of plus features that github deliberately
destroyed in order to make supporting CODE a priority. When PHP project
was looking to move - yet again - Hg get the vote for a system that
worked better, but the 'github' marketing angle won the day - even given
it's know faults! So now I have an Hg/Mercurial setup locally, which
handles CVS, SVN and GIT transparently and allows working easily between
all four. BUT I would still prefer the clean way that CVS handled
modular project. GIT ( and actually Hg) still does not accept that
scripted languages and documentation is much better handled as a series
of inter-related projects rather than one all encompassing code base.
sub-repo's are frond on in both while CVS modules are still a perfect
solution, and projects that broke perfectly good CVS repositories into a
series of GIT repo's still have no tools to put the hwole back together
again.

PHP still has not plugged all the holes in it's GIT process and often
gets cross contamination, so until there IS a reason to change ... why
create all that extra work? And certainly don't put anything on github
... use a private git repository which is the one thing PHP has right.

[Mark Rotteveel]

Post by Lester Caine
CVS still has a number of plus features that github deliberately
destroyed in order to make supporting CODE a priority.

Git != GitHub.

Post by Lester Caine
When PHP project
was looking to move - yet again - Hg get the vote for a system that
worked better, but the 'github' marketing angle won the day - even given
it's know faults! So now I have an Hg/Mercurial setup locally, which
handles CVS, SVN and GIT transparently and allows working easily between
all four. BUT I would still prefer the clean way that CVS handled
modular project. GIT ( and actually Hg) still does not accept that
scripted languages and documentation is much better handled as a series
of inter-related projects rather than one all encompassing code base.
sub-repo's are frond on in both while CVS modules are still a perfect
solution, and projects that broke perfectly good CVS repositories into a
series of GIT repo's still have no tools to put the hwole back together
again.

That is not really an argument against moving the documentation project
given it is only one module.

And technically git has submodules etc, but that is really a pain to
work with, and I've never really had the need for something like that.

[marius adrian popa]

One argument i can give is that i can edit directly the files on github ,
so that is a lot faster for small fixes for the doc area

Post by Mark Rotteveel
Git != GitHub.

But it's the reason most projects use as an excuse to promote git over
other options :(
And it's trying to promote itself as yet another social media site
detracts from the REAL jobs that many years ago SF did so well but
without actually achieving it.
My point is that github is a distraction most of the time and promoting
it more does not help develop a better - fully integrated - solution to
project management. One can have a presence ON github and all the other
alternatives without 'moving to' github ... and moving a perfectly
functional repository does not need git messing it up when it does not
need the compromises git introduces.

So your argument boils down to "I don't like git and GitHub, because
they 'won' the hearts and minds of the majority of the (open source)
development community".
That is exactly one of the reasons I propose to move the repository to
GitHub: that is where the people are, and a lot of people know how to
use it.
Lets face it: the Firebird documentation project could do with more
active contributors. Is moving to GitHub going to solve that: of course
not, but it might make it easier. Moving Jaybird to GitHub last year
lead to at least 4 (small and large contributions), including the
support for SRP.
You mention downsides/compromises that git brings to the table: exactly
what kind of compromises do you think the Firebird documentation project
specifically would experience with moving to git? As far as I know the
manual module is pretty straight-forward with a largely linear history,
and without use of obscure CVS features, so I don't see where those
compromises would be, and I'd really like to know. However, I can name
at least one benefit of moving to git: rename/move or copy with history,
and for moving to GitHub: contributions by pull request.
Also to be clear: I'm talking about moving the repository: the rest can
stay where it is if that is deemed better (eg you can disable issues if
you don't want to use the GitHub issue tracker, etc).
Mark
--
Mark Rotteveel
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
_______________________________________________
Firebird-docs mailing list
https://lists.sourceforge.net/lists/listinfo/firebird-docs

[Mark Rotteveel]

So bouncing in here on a tangent, I've done this with a couple of
Source forge projects, simply set Source forge to clone the Github
project or visa versa. The only reason I would suggest having things on
Github is for more visibility. Anyway my five cents. You can still
continue to commit as always, just have things cloned on both. Each
versioning system has its pros and cons, those of us who started with
CVS may have moved on to use other systems but hey, its such a mission
to switch things that work.

That works (barely) if you already have a git project on SourceForge,
but as far as I know not if you have CVS project on SourceForge.

If a conversion is going to happen (but the strong resistance seems to
indicate no), then I'd prefer going GitHub the way the core project did
as well, instead of having a hybrid solution where you try to balance
between GitHub and SourceForge and having to keep both repositories in-sync.

Mark

[Mark Rotteveel]

Post by Mark Rotteveel
Isn't it time to consider migrating the documentation repository from
SourceForge CVS to GitHub?
SourceForge itself considers CVS deprecated, and having the repository
on GitHub might increase visibility and will likely lower the barrier
for contribution.

*Helen Borrie:* I don't see how moving the source from one obscure
repository to a different obscure repository would heighten visibility
or lower any barrier.

For visibility: the documentation project will be in the same group on
GitHub as the Firebird project itself. This makes discovery of the
project a lot easier.

Also these days GitHub is the go-to place for hosting open-source
projects. More people know git and GitHub than CVS. GitHub provides a
lot of features that simplify contributing to a project even if you
don't have commit rights (eg pull requests).

If there's a good reason to change, I'd go with it, albeit it currently
aint broke so there be nothing to fix. PaulV has it nicely set up for
use by the translators and it is all well documented, enough so that
those of us who actually DO stuff regularly, rather than just talk about
doing it, have our local setups that are more or less automated. One of
us can always step in to assist people who don't want to work with a
repository for whatever reason. I don't see how changing the repository
would (or should) alter that.

The main advantage I see are that one-off contributions become simpler,
and those might lead to more.

My personal experience so far with GitHub is that it is a dog to work
with, actually, given that I don't upload or download any programming
code, only documentation. I guess if I had to, I'd find a way to make
it useful for me to use. I just can't think of a good reason right now
to spend time and energy on creating a solution to a non-existent problem.

As a sidenote: SourceForge considers CVS type projects to be deprecated
these days, don't be surprised if we get a notice in the future that we
need to migrate anyway.

From https://sourceforge.net/p/forge/documentation/CVS/ :

"CVS is no longer available for new projects, we only offer limited
support for CVS for projects previously using it on the Classic
SourceForge system.

We recommend that projects upgrade to a more modern SCM, like
Subversion, rather than using CVS. CVS has limitations which newer SCM
solutions have been designed to overcome. We continue to support CVS for
those projects who decide that CVS adequately supports their needs."

[Mark Rotteveel]

Post by Paul Vinkenoog

Post by Mark Rotteveel
Isn't it time to consider migrating the documentation repository from
SourceForge CVS to GitHub?
SourceForge itself considers CVS deprecated, and having the repository
on GitHub might increase visibility and will likely lower the barrier
for contribution.

No objections here, but does anybody have any experience with this kind
of migration? (Preferably including history.)

I migrated Jaybird from CVS to Subversion and then to git (GitHub). The
migration from Subversion to git was facilitated by GitHub, but their
tooling does not support CVS. However the tool I used to go from CVS to
Subversion also has a variant to go to git.

Mark