invoke python2.7 for mmseg #3244
Conversation
|
I just found out that gale_mandarin recipe, which is way outdated (not even
nnet2), is also using mmseg... Does it deserve a fix?
…On Thu, Apr 18, 2019 at 2:15 PM Daniel Povey ***@***.***> wrote:
Merged #3244 <#3244> into master.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3244 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAZKTRG2BNAJ5YA2XOWW3QTPRAGZNANCNFSM4HGZ6Q5Q>
.
|
|
My take is that keeping dead recipes in egs/ is not the best approach overall. If all it takes is the same 3-line fix, I would. But that's a good general question. Since the egs are often part of published/reproducible results, they better be kept, but they become a maintenance burden. But Git remembers everything; anyone can get an eg and the codebase as they were when a recipe was published. It makes sense to me to keep only the README and RESULTS files for outdated egs, and add a note to the README how to get the old eg code by its commit (simple instructions to the user how to do it, like |
|
I would prefer to keep the outdated egs somewhat alive, and in the repo in
the normal way, although perhaps we could add warnings.
The issue is that someone has done the work to set up the data preparation
scripts for those datasets,
and there is value in that even if the recipes are not up to date; and
people find those recipes and eventually update them if they are
interested. Putting up more barriers to entry could impede that process.
For example, someone just submitted an update for the RM recipe which had
been outdated for ages. If we had made that more inaccesible that might
not have happened.
…On Thu, Apr 18, 2019 at 10:39 AM kkm (aka Kirill Katsnelson) < ***@***.***> wrote:
My take is that keeping dead recipes in egs/ is not the best approach
overall. If all it takes is the same 3-line fix, I would.
But that's a good general question. Since the egs are often part of
published/reproducible results, they better be kept, but they become a
maintenance burden. But Git remembers everything; anyone can get an eg and
the codebase as they were when a recipe was published. It makes sense to me
to keep only the README and RESULTS files for outdated egs, and add a note
to the README how to get the old eg code by its commit (simple instructions
to the user how to do it, like git checkout deadc0de42). git blame RESULTS
is the best way to see the history of reference results at a glance; this
file receives no other edits in practice; mentioning the command could be a
good idea too, We probably should get to it when Dan has a breather.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#3244 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAZFLO3F2IHRDXKQ7WFEDMDPRCW37ANCNFSM4HGZ6Q5Q>
.
|
|
@danpovey, this makes sense. Even outdated egs can serve as examples. This requires marking them as no longer maintained, and that the users have an easy way--they do, I should say rather say know the easy way to pull the historical working slice. And I also see how people submit PRs, on top of random outdated branches. Both these issues converge on a more efficient use of Git by the users. I understand why do you rebase/collapse when merging: this is mainly because how the patches are sent in, sometimes on top of random branches neglected for years. Merging there as normal topo merge commits would turn the log graph into a horryfying bundle of capellini. So I have been pondering writing a guide on efficient Git use for Kaldi users and occasional contributors. We touch on that in the docs, but just too briefly. I'm going to start when I have less rush at work. Are you ok with putting it into the main repo Wiki section on GitHub? It can be collaboratively edited there, too. We could convert them into a docx by the end, or leave there--that we could decide later. Is this ok by you? |
|
A guide for git usage is a good idea, I think.
I think it will be difficult to mark recipes as maintained or
not-maintained, because in reality it's a continuous
spectrum. Telling people in a prominent place which recipes they should
look at first
(e.g. mini_librispeech, swbd/s5c) might be a good idea though.
…On Thu, Apr 18, 2019 at 8:36 PM kkm (aka Kirill Katsnelson) < ***@***.***> wrote:
@danpovey <https://github.com/danpovey>, this makes sense. Even outdated
egs can serve as examples. This requires marking them as no longer
maintained, and that the users have an easy way--they do, I should say
rather say know the easy way to pull the historical working slice. And I
also see how people submit PRs, on top of random outdated branches. Both
these issues converge on a more efficient use of Git by the users. I
understand why do you rebase/collapse when merging: this is mainly because
how the patches are sent in, sometimes on top of random branches neglected
for years. Merging there as normal topo merge commits would turn the log
graph into a horryfying bundle of capellini.
So I have been pondering writing a guide on efficient Git use for Kaldi
users and occasional contributors. We touch on that in the docs, but just
too briefly. I'm going to start when I have less rush at work. Are you ok
with putting it into the main repo Wiki section on GitHub? It can be
collaboratively edited there, too. We could convert them into a docx by the
end, or leave there--that we could decide later. Is this ok by you?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3244 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAZFLO7NWOQO565QOGR3TXLPRE43XANCNFSM4HGZ6Q5Q>
.
|
|
Yup. I noticed most first-timers tend to start with the largest dataset they can get hold of (my first was tedlium). I like learning stuff the hard way, but I know for others it may be discouraging. @naxingyu, by the way, FYI:
The list of keywords GH understands: https://help.github.com/en/articles/closing-issues-using-keywords. "Fix", "fixes" or "fixed" would do it, but "fixing" they do not match. |
|
@kkm000 oh, didn't know that, thanks! |
For fixing #3238