Menu
▾
▴
firebird-docs
|
From: Mark R. <ma...@la...> - 2016-12-16 13:32:37
|
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 -- Mark Rotteveel |
|
From: Paul V. <pa...@vi...> - 2016-12-17 22:46:48
|
Mark Rotteveel wrote: > 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 |
|
From: Mark R. <ma...@la...> - 2016-12-18 11:02:22
|
On 17-12-2016 23:46, Paul Vinkenoog wrote: > Mark Rotteveel wrote: > >> 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 -- Mark Rotteveel |
|
From: Helen B. <he...@ii...> - 2016-12-18 02:24:17
|
On 18/12/2016 11:48:34 AM, Paul Vinkenoog <pa...@vi...> wrote: Mark Rotteveel wrote: > 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 |
|
From: Mark R. <ma...@la...> - 2016-12-18 11:16:32
|
On 18-12-2016 03:24, Helen Borrie wrote: > >> On 18/12/2016 11:48:34 AM, Paul Vinkenoog <pa...@vi...> wrote: >> >> Mark Rotteveel wrote: >> >> > 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 |
|
From: Lester C. <le...@ls...> - 2016-12-18 10:08:52
|
On 18/12/16 02:24, Helen Borrie wrote: >> Mark Rotteveel wrote: >> >> > 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. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk |
|
From: Mark R. <ma...@la...> - 2016-12-18 11:20:20
|
On 18-12-2016 10:41, Lester Caine wrote: > CVS still has a number of plus features that github deliberately > destroyed in order to make supporting CODE a priority. Git != GitHub. > 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. -- Mark Rotteveel |
|
From: Lester C. <le...@ls...> - 2016-12-19 10:08:55
|
On 18/12/16 11:19, Mark Rotteveel wrote: > 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. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk |
|
From: Andre v. Z. <an...@sp...> - 2016-12-19 10:39:35
|
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. On Mon, Dec 19, 2016 at 12:08 PM, Lester Caine <le...@ls...> wrote: > On 18/12/16 11:19, Mark Rotteveel wrote: > > 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. > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk > Rainbow Digital Media - http://rainbowdigitalmedia.co.uk > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Firebird-docs mailing list > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firebird-docs > -- <http://spiceware.co.za> |
|
From: Mark R. <ma...@la...> - 2016-12-19 16:56:25
|
On 19-12-2016 11:39, Andre van Zuydam wrote: > 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 |
|
From: Mark R. <ma...@la...> - 2016-12-19 17:13:58
|
On 19-12-2016 11:08, Lester Caine wrote: > On 18/12/16 11:19, Mark Rotteveel wrote: >> 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 |
|
From: marius a. p. <ma...@gm...> - 2016-12-19 18:12:26
|
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 On Mon, Dec 19, 2016 at 7:13 PM, Mark Rotteveel <ma...@la...> wrote: > On 19-12-2016 11:08, Lester Caine wrote: > > On 18/12/16 11:19, Mark Rotteveel wrote: > >> 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 > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firebird-docs > |
Thanks for helping keep SourceForge clean.
X