Re: [Kaldi-developers] Testing Github repository

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

Vassil, the transition period is mostly for the active kaldi developers --
to give them time to learn git, finding out the best way for the
transition, writing docs, deciding on the workflow (and to allow them to
make mistakes). If the SVN stays as the primary repository during this
period, all the mistakes are non-fatal (we can always delete everything and
recreate the git repo again from SVN).
y.

On Tue, Apr 7, 2015 at 5:24 AM, Vassil Panayotov <vas...@gm...
> wrote:

> FWIW +1 from me to the migration to Git. Don't know if that will really
> encourage people to contribute more, but some say the ease of creating pull
> requests is helpful... Having a "Kaldi" GitHub organization may also
> increase the visibility of projects, built on top of Kaldi(e.g. Tanel
> Alumae's ASR server), or related to Kaldi(like PDNN or the Python wrappers
> that were discussed here not long ago). GitHub's support for organizations
> is really basic (AFAIK they don't even support following an organization),
> but hopefully they will (finally) improve that.
>
> IMHO the workflow suggested by Kirill, where everyone submits pull
> requests to the "official" repository, that are merged (possibly after a
> review) seems good. I don't think the branching will be a problem. As I
> understand it, in the proposed workflow the history of the official repo
> will be entirely linear(fast forward commits into "master"). I've mostly
> used Git with single-user(i.e. me) repositories so far, but AFAIK it only
> becomes problematic if you rewrite the history by rebasing or amending
> commits in a branch that is jointly worked on with others. And even if that
> happens it should be easy to recover, because with Git everyone has the
> full project history on his desktop.
>
> It's not very clear to me if this transition period of few months is
> needed and how it would be helpful if people are still using only SVN? I'd
> say if everyone agrees that Git is the way to go, the switch can be made as
> soon as the process of switching and the new workflow are documented. From
> the user's viewpoint it probably won't matter much if they type "svn up" or
> "git pull origin master". Also, I agree with Kirill that keeping SVN in
> sync after the switch could be probably an unnecessary hassle. Having a
> backup is obviously not a problem, because in couple of days of migration
> to Git, there will be enough full copies of the history distributed around
> the world to survive a dinosaur extinction- causing event (even though the
> usefulness of Kaldi in the aftermath is uncertain...).
>
> I haven't been involved with such migrations though, so maybe I'm
> overlooking something...
>
> Vassil
>
>
> On Tue, Apr 7, 2015 at 9:12 AM, Alexander Solovets <aso...@gm...>
> wrote:
>
>> Jan, I don't know how Nikolay does it, but I simply download and
>> apply the diff, and then run `git svn dcommit`. I know that you can
>> also accept the pull request into a custom branch (i.e. non-master).
>> In this case you can do it via GitHub's UI, and then rebase that
>> branch on top of master and push changes.
>>
>> Kirill, by "branching hell" I meant non-linear history with a lot of
>> "merge" points. You not only loose the linearity, but also the merge
>> conflict resolution becomes way more complex, the chance to
>> accidentally drop someone else's changes increases. I do know about
>> variety of git workflows and different techniques of accepting new
>> commits, and I'm not going to argue, I just wanted to share my
>> experience.
>>
>> On Tue, Apr 7, 2015 at 1:47 AM, Kirill Katsnelson
>> <kir...@sm...> wrote:
>> >> -----Original Message-----
>> >> From: Daniel Povey [mailto:dp...@gm...]
>> >> Perhaps you could explain how this is done?
>> >> It might help us make an informed decision if you could give us some
>> >> details on the workflow that you use, at the level of specific
>> >> commands.
>> >
>> > Let me set up a pair of cloned demo repositories to show different
>> practices, as time permits. Give me a day or two.
>> >
>> >  -kkm
>> >
>> ------------------------------------------------------------------------------
>> > 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
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>
>