> Date: Sat, 3 Feb 2018 16:03:48 -0800 > From: Shardul Chiplunkar <[email protected]> > To: [email protected], > apertium-pmc <[email protected]> > Reply-To: [email protected] > Subject: [Apertium-stuff] Proposal: Move Apertium to Github > Pièce(s) jointes(s) probable(s)> > To the President and members of the PMC and Apertium contributors, > > There is a new proposal to the PMC to move Apertium to Github: > http://wiki.apertium.org/wiki/PMC_proposals/Move_Apertium_to_Github > > Both previous proposals of a similar topic had shortcomings which this > proposal tries to address. > > If you are not a member of the PMC but would like to express your support > for this proposal, please add your name to the "Non-PMC signatories" > section at the bottom of the page. > > Thank you, > Shardul C. >
Well, I preferred watching information about git before taking part of this debate. First, your proposal, as previous ones about it includes 2 changes in the same package : 1) leaving sourceforge.net to go to github.com 2) leaving subversion to use git According to what we need, these 2 changes can be examined separately. Do we have a reason to leave sourceforge.net ? (I heard about problems with this provider during the last years). if yes, we can move to another provider supporting subversion. Do we have a reason to leave subversion and to use git instead ? If yes, we can move to git while staying on sourceforge.net . About using git instead of subversion : For downloading the last version of an Apertium tool or a language pair, there is a simple command line both with subversion and git. And this command does not need any password. So this minimal requirement is reached for the two software. I hope sending changes with git will be as simple as a svn commit , but I am really not sure. According what I saw about git, it promotes the creation of different forks where apertium tendency is to use the same reference files in different language pairs. For a 6 months period, there is generally one or two commiters working on a particular language pair + eventually PMC members doing the same changes on any pairs, (but these changes are not on dictionaries or transfer rules), so, this is not a problem if the commiter just create a new reference development version using a svn commit. When apertium project started, the first language pairs included any requested file. And if a new language pair was created, several files of other language pairs like monodices were just copied. After that, each version of a monodix of the same language could evolve separately by adding word inside. After, it was decided to do common file for languages. A good idea, but it seem these reference files were done just by taking the file of one of the possible pair. So, for French, the epo-fra French monodix has a really wider word coverage than the official French monodix. And I also added several words in fra-por pair. I also added RL definitions in paradigms giving mf or sp attributes for analysis. It simplifies transfer and generation. In the future, when it will be time to release one of these pairs, another reference file for French monodix will have to be done including the present reference and the specific adds which are inside epo-fra and fra-por French monodices. (I was asked not to prepare this file from now). And then, language pairs using now the present reference file will have to be tested with the new one to prevent regression. So, after that, my new reference monodix will become the new reference French monodix working with 2 more language pairs. But what would be a transitional step with subversion (2 reference files) for a as shortest as possible amount of time, could be the general behavior if we move to git. Git seems to allow very easily disorder. About broadcasting a change to the world. You seem to see as a problem to a student to ask for a commit access that would get valid, if accepted, for the whole Apertium project. But how will it work with git ? If we give to anybody the right to do other official versions without even been known by anybody of Apertium project, that will be the most simple way to work for the regular and serious apertium commiters, but that's not safe. If we give only this right to chosen Apertium commiters, how will they be chosen ? I think when somebody creates a new language pair, it's normal to give him these right for it. But what will happen if several years after, another person makes changes ? Will it be always possible to reach the first commiter who may have left Apertium project without telling it, and who may have even lost his email address if it was a university email ? Another possibility would be to ask PMC member to verify the validity of a change in a pair without even knowing any language of this pair ! That would give a lot of extra work for PMC members actually not needed with subversion. You also write that new people knowing git will not have, if we switch to git, to learn subversion commands. True but : - svn checkout to know for downloading something from Apertium - svn commit to know to broadcast a change. That's all what is requested to work on a language pair. In addition, in more than 5 years, I may have used once or twice svn move and svn del , a little more often svn add (useful for a new pair) and I use svn list in scripts. According to the size of git man pages, learning git when we know subversion may take a full month ! For instance what is done with svn list seems to be an option of git-branch (???) and as git branch allow also changes (copy etc...), is it sure the list command will be available without been connected ? If not, that will not allow automatic commands scanning changes into Apertium modules which simply works with subversion, and it will be an important regression for me. According to the choice of the provider if we choose to move to git, you prefer github because it is the most used for free software. It's the same attitude as with people thinking the only software existing for text processing (and sometimes even for raw text editing) is called w...d (in 4 letters). So, if github is a place where your student can fins a lot of free software, putting Apertium on another place will be an occasion for them to learn something more : it's possible to find free software outside github. I was thinking to https://framagit.org/ There are a lot of websites named frama(...).org as alternative to big enterprises solutions : https://degooglisons-internet.org/alternative (in French but there are translators and software names don't change). But in fact, framagit is an instance of gitlab known by some of you. -------------------------------- Bernard Chardonneau (France) Phone : [33] 9 72 36 32 90 GSM phone : [33] 7 69 46 16 31 Multilingual websites for my free softwares : http://libremail.free.fr and http://libremail.tuxfamily.org http://cyloop.tuxfamily.org (mainly translated with Apertium) My general website (in french only) http://bech.free.fr ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Apertium-stuff mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/apertium-stuff
