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
repository.
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
changes.
5. The changes are reviewed. If they are acceptable, they are added, and now
'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
quality.
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/issues/7
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>
wrote:
> > Date: Sat, 3 Feb 2018 16:03:48 -0800
> > From: Shardul Chiplunkar <shardul.chiplun...@gmail.com>
> > To: apertium-stuff@lists.sourceforge.net,
> > apertium-pmc <apertium-...@dlsi.ua.es>
> > Reply-To: apertium-stuff@lists.sourceforge.net
> > 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
> Apertium-stuff@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/apertium-stuff
>
------------------------------------------------------------------------------
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
Apertium-stuff@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/apertium-stuff
