Re: [Kaldi-developers] Testing Github repository

[Jan T. <af...@ce...>]

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_SF
> _______________________________________________
> Kaldi-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>