Hi Bernard
I'll try to summarize the answers for your main concerns. If I'm not
answering an specific question, please let me know and I'll try to make
sure it gets covered.
The proposal is to move both to GitHub and git, for several reasons
explained in the wiki page.
Regarding your concerns with git itself, git allows for more complex
workflows, but that doesn't mean those workflows have to be done. We may
probably want to follow different approaches for tools (where I can easily
foresee people using many branches, creating pull requests,... using
"advanced git") while, at the same time, just using "git commit && git
push" (very similar to "svn commit") for language pairs where there is only
one or two developers. And I'm sure you won't need a month to learn the git
basics. In any case, no need to involve the PMC to review any change
happening on any of the modules.
If you want to do a "svn list", you just need to do "git ls-files": you get
exactly the same output. It has nothing to do with git branch. In any case,
with git you can do many things that you cant with SVN, like doing commits
when you have no internet access, etc.
Regarding the monolingual packages (i.e. apertium-fra) vs old packages with
monolingual dictionaries included, there will be no change: the
current goal is to slowly move to packages with the monolingual data
outside the translation pair, and that won't change when moving to git. At
the same time, there won't be any requirement to "force" anyone the change
the existing language pairs to use monolingual packages because of the
transition to git. There's no implicit disorder/order regarding how we
structure our language pairs that comes with git or SVN. So, everything
will remain the same in this case.
Regarding "official versions", they will be in repositories under the
Apertium organization, so there is no risk of losing any "official" package
because someone changed their email. But it will allow us to handle
permissions in a fine grain mode: some committers may only want/need access
for a specific language, or a set of language pairs, or a set of tools, and
that will be possible to manage. But, again, that's doesn't prevent that
full permissions are given to some committers that need access everywhere
in the code.
And regarding "github" or a different provider, Github has something good:
the community effect. But that doesn't mean that it has to be the "only"
source. In fact, with git is much easier to have multiple repositories than
with SVN, and we may want to have a full copy of all Apertium repositories
in another server (i.e. in apertium.org) to act as a backup, or even change
in the future to a hosted GitLab instance (like framagit, the one you
share).
I hope this helps!
2018-02-07 18:54 GMT+01:00 Bernard Chardonneau <bechapert...@free.fr>:
>
> 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.
>
>
>
--
< Xavi Ivars >
< http://xavi.ivars.me >
------------------------------------------------------------------------------
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
