Re: [Kaldi-developers] Testing Github repository

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

Or maybe let me phrase the question differently: how much automatic can it
be done  (and I realize that we might not want to do it fully automatic)
and how is it done :)
y.

On Mon, Apr 6, 2015 at 4:16 PM, Jan Trmal <af...@ce...> wrote:

> Alexander, can you send show us (i.e. how this is done on command-line
> level) how this is done?
> y.
>
> On Mon, Apr 6, 2015 at 3:59 PM, Alexander Solovets <aso...@gm...>
> wrote:
>
>> 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_SF
>> >> _______________________________________________
>> >> 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
>>
>
>