Re: AW: Development - an outsider’s perspective

[Carsten Wenderdel]

Hi Philippe,

thanks for your detailed answer!


> I converted the gnubg and gnubg-nn subdirectories in separate git repos. 
> This seemed more natural to have gnubg at the root of its repo.

Yes, separate repositories might also make sense, I don't know what's better.
Having both in one repository (for now), would also allow to see a combined 
commit history.
And once everything is git, we can move/rename folders without losing that 
history.
But if those two modules are completely separate and we never want to share 
code between, then two repositories are more suited.


> FWIW, what I did was :
> rsync -av rsync://cvs.savannah.gnu.org/sources/gnubg/ gnubg-full-cvs/
> cvsconvert -v -A authormap gnubg-full-cvs/gnubg
> Then, in the created gnubg-full-cvs-gnubg-nn-git directory :
> git gc --aggressive
> git checkout master

My commands for cvs2git:
rsync -av rsync://cvs.savannah.gnu.org/sources/gnubg .
cvs2git --blobfile=./git-blob.dat --dumpfile=./git-dump.dat --keep-cvsignore 
--retain-conflicting-attic-files --encoding=ascii --encoding=utf8 
--encoding=utf16 --fallback-encoding=utf8 ./gnubg
mdkir gnubg-cvs2git && cd gnubg-cvs2git && git init
cat ../git-blob.dat ../git-dump.dat | git fast-import


> > Another open question: As “author” git would always use the user 
> > handle of the CVS committer. Do we want to have full name and email 
> > address instead? That’s possible if those tools would be fed with a 
> > file mapping those user handles (like “plm”) to full name / email 
> address.
> > As with CVS committer and author often were different people this 
> > might not be wanted though.
> 
> As the command I gave earlier show, I think it would be preferable to 
> have real names and adresses rather than savannah handles, but I don't 
> understand your last sentence. I think most of the time the committer 
> was the author of the change ; the latter may sometimes have been an 
> occasionnal contributor who may or not have been credited in the 
> comment, but using names and adresses would allow to do it more 
> systematically in the future, wouldn't it ?

I'm not sure I understand you correctly. Once using git, we would use full name 
/ email address anyway. This discussion is only about the commit history until 
now, not the future git commits.


> What puzzles me most in your suggestions is this :

> > So my suggestion is to first move the repository to GitHub. 

> Moving to gitub doesn't seem especially urgent to me. First task would 
> be ensure that the conversion to a git repo is done right. Your report 
> shows some uncertainties in this regard.

That was poor wording on my side. With "first" I meant this should be done 
before my other suggestions are tackled, like refactoring of the code base. 
Renaming of files is much better handled in git than in CVS, the history and 
"git blame" can deal with that.

I completely agree with you that first we need a proper export to git and 
should give it enough time until we are certain of it.

Another detail: when I took another look at the two exports I did, I noticed a 
different number of commits (7285 vs 7532)
The reason is that sometimes one commit in cvs2git is two when using 
cvs-fast-export:
https://github.com/carsten-wenderdel/gnubg-cvs2svn/commit/393d20d338873e83ef318b9cba756fba14753fce
https://github.com/carsten-wenderdel/gnubg-fast-export/commit/92976ccb98d1d4a695170f34ae762312ce06523b
https://github.com/carsten-wenderdel/gnubg-fast-export/commit/c584bf27a7c610cd3bda9d4eec6e52b25a73c048

cvs2git also omits the CVS comments like
 * $Id: matchequity.c,v 1.106 2022/02/19 21:52:48 plm Exp $
We don't need them anymore, so that should be ok.


> Then I would find it natural to clone it to savannah (and, I suppose, 
> have the cvs repository made unavailable or at least read-only). That 
> would already allow anyone interested to easily clone the repository 
> locally, to github, or elsewhere.
>  
> Only then could it be envisaged to move the reference origin (and 
> possibly everything else, bug reporting, binaries distribution, mailing 
> list) elsewhere.

Personally I would skip the step via savannah. But yes, moving a git repository 
from savannah to somewhere else is very simple, quick and wouldn't change 
commit history.


> I must be out of touch with the modern open source ecosystem but
> 
> > Some developers care about their contribution statistics on GitHub
> 
> came as a surprise to me.
> 
> A significant enough contribution to have one's name in a documentation, 
> readme, changelog? Great! Bug reports and occasionnal suggestions for 
> something I use? Obviously! But going in priority where there are 
> counters to inflate ???

I have only anecdotal data, but many people in HR hiring software engineers ask 
for your GitHub handle.
Even when applicants are not asked, I have seen many of them giving the URL to 
their account in their CV.
It's not only about numbers, it's also an easy way to check the quality of 
those contributions.
And yes, some people also inflate those numbers and brag about it, just check
https://twitter.com/search?q=github%20contributions%202022
Maybe we should stop discussing contribution statistics here, but for gnubg you 
would definitely win 2022 :)

Best regards,
Carsten