Menu
▾
▴
Re: [Kaldi-developers] Testing Github repository
|
From: Kirill K. <kir...@sm...> - 2015-04-07 00:39:21
|
It is not immediately clear what do you call the "branching hell" (this emphatic name has been applied to a variety of conditions), but, looking at the way Kaldi is being developed, there seems no place for big branching screw-ups. All work basically happens on a single branch, and there is a multitude of private sandboxes, sending patches once in a while. This is already one step closer to a "branching hell" in one possible sense than the development workflow when these sandboxes are separated into users' private clones. This workflow is even more linear than the current Kaldi svn flow. I would argue that it all comes to good housekeeping practices rather than to a stipulated inherent proneness of git to compounded branching conditions. Handling 2 different SCS is indeed a problem. I really doubt that maintaining the content in 2 repositories is worth the effort in the long term. (And remember, this is the time that will not be spent on the main speech recognition work.) FWIW, the cmusphinx/sphinxtrain has seen 3 pull requests in the 5 months since the first one, of which 2 were approved and applied. Kaldi's rate of changes is two order of magnitude higher. -kkm > -----Original Message----- > From: Alexander Solovets [mailto:aso...@gm...] > Sent: 2015-04-06 1300 > To: Jan Trmal > Cc: Kirill Katsnelson; kal...@li... > Subject: Re: [Kaldi-developers] Testing Github repository > > I would recommend to stick to SVN as long as possible just because when > the history is linear you can easily convert repository from one VCS to > another. When the git branching hell comes you'll have to stay with it > forever. On CMU Sphinx when a pull request is received, it actually > goes to SVN first and then is closed with the revision number in the > comment, like this https://github.com/cmusphinx/sphinxtrain/pull/4. > > On Mon, Apr 6, 2015 at 8:04 PM, Jan Trmal <af...@ce...> wrote: > > Kirill and all, > > first, thanks for your comments and encouragement As it looks right > > now, we will have only single, trunk, branch in the repository (we > > might even delete the stable branch). > > During a few past days, I have imported the kaldi repository once > > more. The reason was that if you select the project's licence during > > repository creation on github, github will commit some files into the > > repository (LICENCE file at least) and that messed up the commit > > history so that git svn rebase didn't work -- I had to do recursive > > merge every time before I called rebase and everything was getting > out > > my control. There might be easy fix for this, but the most > > straightforward way for me was to run the conversion again. After > > that, the svn rebase work smoothly (I have a cron job taking care of > it now). > > > > During this week, I intend to do the conversion once more again and > > hopefully for the last time (i.e. after that, we will have an > official > > kaldi git repository mirroring changes from SVN) The current > tentative > > plans for kaldi transition is: > > * first, for a few months, operate the github kaldi repo as an > > official mirror of svn. That means all commits will go to SVN and the > > less adventurous users (and possibly companies with more inflexible > > workflow) can keep using SVN. This is to give us time to sort out the > > issues, write up the docs and get familiar with git > > * after that, we can make the git repository primary and instead of > > mirroring SVN->GIT we will mirror GIT->SVN (note: I still have to > > figure out if this is feasible -- but I think it is). This should > > -force- motivate all users to switch to GIT > > * after that (or right after skipping the previous stage completely) > > keep only git and stop using and supporting SVN. > > > > y. > > > > > > > > > > On Mon, Apr 6, 2015 at 2:36 PM, Kirill Katsnelson > > <kir...@sm...> wrote: > >> > >> Totally true. Depending on the type of workflow that Kaldi > developers > >> see, there are up to 3 cloned repositories involved. This is what > >> happens in the project I maintain > >> (https://github.com/fsprojects/FsLexYacc). We do not accept any > other > >> way to submit changes to the main repository (which is a bare repo > in > >> github) than using github's pull requests. Even people with write > >> access to the repo must follow this path. Since the pull request may > >> only be generated in github between 2 branches on repos necessarily > >> stored on gihub (although the branches may be in different repos, > >> having a common history fork in the past), the patch submitter must > have cloned the main repo at some point. This is the clone #2. > >> > >> Since the submitter obviously has to do some hacking first, he > clones > >> his github clone #2 to a desktop, locally, and this is the clone #3. > >> He normally pushes into a branch or the master "trunk," and, come > >> time to send the changes upstream, issues a pull request for a diff > >> between clones #1 and #2 (or 2 points in history in #2). > >> > >> The only tricky part here is merging upstream changes into this > train > >> of clones (analogous to "svn update") in such a way that the > upstream > >> changes would not show up in the resulting pull request. > >> > >> Another workflow would be allowing changes into the main trunk > branch > >> "the svn way." To me, the main benefit of having the pending commits > >> (as pull > >> requests) inspected by the peers is lost in this workflow. But the > >> decision is on Kaldi dev's I any case. > >> > >> It perhaps makes sense to write up a walk-through for first time git > >> (or > >> github) users. I'd take on the task, but I need to play back the > >> step-by-step as I write, so I need time for the task. A workflow > >> decision must be done first, however. There might also be an > existing > >> guide on the 'Net for those migrating from svn into the selected git > workflow. > >> > >> -kkm > >> > >> > -----Original Message----- > >> > From: Phil Garner [mailto:Phi...@id...] > >> > Sent: 2015-04-05 0622 > >> > To: kal...@li... > >> > Subject: Re: [Kaldi-developers] Testing Github repository > >> > > >> > > So far, I pushed only the trunk and stable branch -- I'm not > sure > >> > > if import of all sandboxes makes sense. > >> > > >> > If I understand the concept of sandboxes well, then in git they > may > >> > better correspond to branches in user clones of the repository. > >> > That is, the person responsible for the sandbox clones the trunk > >> > repo and commits to a branch as they wish. Github makes this very > easy. > >> > > >> > -- > >> > Phil Garner > >> > http://www.idiap.ch/~pgarner > >> > > >> > > >> > ------------------------------------------------------------------ > - > >> > ---- > >> > ------- > >> > Dive into the World of Parallel Programming The Go Parallel > >> > Website, sponsored by Intel and developed in partnership with > >> > Slashdot Media, is your hub for all things parallel software > >> > development, from weekly thought leadership blogs to news, videos, > >> > case studies, tutorials and more. Take a look and join the > >> > conversation now. http://goparallel.sourceforge.net/ > >> > _______________________________________________ > >> > Kaldi-developers mailing list > >> > Kal...@li... > >> > https://lists.sourceforge.net/lists/listinfo/kaldi-developers > >> > >> -------------------------------------------------------------------- > - > >> --------- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM > >> EDT Develop your own process in accordance with the BPMN 2 standard > >> Learn Process modeling best practices with Bonita BPM through live > >> exercises > >> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > >> event?utm_ > >> > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_S > >> F _______________________________________________ > >> Kaldi-developers mailing list > >> Kal...@li... > >> https://lists.sourceforge.net/lists/listinfo/kaldi-developers > > > > > > > > --------------------------------------------------------------------- > - > > -------- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > > Develop your own process in accordance with the BPMN 2 standard Learn > > Process modeling best practices with Bonita BPM through live > exercises > > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > > event?utm_ > > > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > > _______________________________________________ > > Kaldi-developers mailing list > > Kal...@li... > > https://lists.sourceforge.net/lists/listinfo/kaldi-developers > > > > > > -- > Sincerely, Alexander |
