> Which leave these staying behind: > - click.py, which ensures "clickable" anaconda info bars have something to > click > - contexts.py, which ensures that strings with keyboard accelerators have > a translation context. Stuff from outside anaconda shouldn't be adding > keyboard accelerators > - gettext_potfiles.py, which ensures we keep POTFILES.in up to date. > anaconda is the only one using autotools so the only one with a POTFILES.in > - style_guide.py, which checks that we say "host name" instead of > "hostname" and stuff like that. I dunno, maybe every project should get that > treatment? Argue your case. Some of these may apply to blivet-gui, though. > Discussion question: should this stuff go in a for-real package in Fedora? > The pros would be easier release-time testing (could be an automatic part of > rc-release or similar), integration with make ci, and Chris wouldn't need to > configure any new stuff in jenkins. Cons would be that there's another > package in Fedora and that testing translations in make ci would be adding > yet more things out of our control. I don't think it needs to be a real package in Fedora. I made pocketlint one, though in retrospect I kind of wish I hadn't. This is just stuff used in the process of us testing and building other software. I'm not concerned about having to set up more stuff in jenkins. I'm pretty used to it by now. If it's not a real package, we'd need some way of checking the tests out from git either into an existing source repo or alongside it and then running the tests. Checking it out into the repo of the thing being tested would probably be much easier to do in jenkins. > As far as how all of this looks, I was thinking just a directory of checkers > (maybe convert gettext_warnings.sh to python for consistency) and a script > that runs them all. I suppose how the script finds the checkers depends on > how real of a program we want it to be, whether it would need an argument to > the directory or could just search via python imports. Sounds good to me. - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
