We've now written all the scripts required for the migration. The scripts
and documentation are available here:
The only issue remaining is of backwards compatibility with the SourceForge
repository. Due to the technical details of SVN, we have two options:
1. Using 'propset': (as an example) When a user checks out the top
directory or the 'incubator' directory from SVN, all the subdirectories
will actually be external pointers to the GitHub SVN bridges for the
corresponding directories, automatically using the latest code from the
GitHub repositories. However, when a user checks out just the
'apertium-eng' directory from SVN, either the directory will be empty or it
will have yet another subdirectory called 'apertium-eng' pointing to the
appropriate GitHub repository, depending on what we choose to do. It is
unfortunately not possible to directly check out an external pointer in
SVN. (Note: if we go with this option, the HTTP interface at
https://svn.code.sf.net/p/apertium/svn/ would be effectively blank.)
2. If the above option is undesirable, we would simply not have backwards
compatibility and would need a clear, not-easily-missed message wherever
required that the SourceForge repository is not updated anymore. It could
be marked read-only or deleted altogether.
We request your comments and suggestions for how to proceed. Except for
this issue, everything else required for migration is ready to go. Thank
(P.S. As Apertium has been selected for GSoC this year (hooray!), we hope
this goes through as soon as possible before March 12.)
On Wed, Feb 7, 2018 at 4:39 PM, Shardul Chiplunkar <
> Hi Bernard,
> Xavi has covered a lot of points that you were asking about. I'd just like
> to add a few more.
> First: Github offers an SVN bridge. This means that if we shift to Github,
> developers who
> want to continue using SVN can use all the same SVN commands and workflows
> as before.
> The only difference will be, when running svn checkout, the URL will be
> github.com and not
> sourceforge.net. After that checkout the developers will not even need to
> be aware that they
> are using Github, and SVN will work exactly as before.
> Second: Here is how pull requests work. (As Xavi mentioned, this is an
> optional thing which
> may be used by only some packages, but I think it is important.)
> 1. A group of users called 'apertium' is the owner of all the repositories.
> For example, 'apertium/apertium-fra'.
> 2. Any developer can create a personal copy of any repository, called a
> 'fork'. The developer
> is the owner of the fork but 'apertium' is still the owner of the original
> For example, 'shardulc' creates the fork 'shardulc/apertium-fra'.
> 3. The developer makes some changes on the fork.
> For example, 'shardulc' adds some commits to 'shardulc/apertium-fra'. This
> does not change
> 'apertium/apertium-fra' because it is a separate repository.
> 4. The developer submits a pull request to the original repository.
> Basically, this means the
> developer is saying to the original repository, "please look at the
> changes I have made and
> add them to the original repository". 'apertium/apertium-fra' is still not
> changed, but whoever
> is in charge of the package is informed that a developer wants to add some
> 5. The changes are reviewed. If they are acceptable, they are added, and
> 'apertium/apertium-fra' and 'shardulc/apertium-fra' have the same code. If
> they are not
> acceptable, the reviewer can tell 'shardulc' what he should change and it
> goes back to step 3.
> Some benefits of using this model:
> 1. It is very easy to make personal changes to Apertium. To make a fork,
> the developer just
> needs to click a button on Github. The developer does not even need to be
> related to Apertium.
> The developer can do whatever they want with the code for personal use and
> Apertium's code
> will be unchanged.
> 2. If the developer wants to add the changes to Apertium, there can be
> pull requests, and most
> importantly, there can be reviews. Of course new developers will not
> produce high quality code
> all at once, and tips from experienced developers will be very useful;
> even experienced
> developers can review each other's code (everyone makes mistakes) and this
> will improve code
> 3. Reviewing pull requests, creating and resolving issues, assigning who
> should work on what,
> etc. is very easy on Github because of its superior interface. As a recent
> example, you can see
> the interaction between me and Sushain in these two links:
> https://github.com/sushain97/apertium-on-github/pull/11 (click on
> "show outdated")
> More benefits/concerns are mentioned on the wiki page and I have also
> replied to your
> comments there. Hope this helps!
> Shardul C.
> On Wed, Feb 7, 2018 at 9:54 AM, Bernard Chardonneau <bechapert...@free.fr>
>> > Date: Sat, 3 Feb 2018 16:03:48 -0800
>> > From: Shardul Chiplunkar <shardul.chiplun...@gmail.com>
>> > To: firstname.lastname@example.org,
>> > apertium-pmc <apertium-...@dlsi.ua.es>
>> > Reply-To: email@example.com
>> > 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
>> > 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
>> 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 :  9 72 36 32 90
>> GSM phone :  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)
>> 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
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