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! |
3 participants
For fixing #3238