Maybe we should create a set of lxde-devel tools and make this a standard develop-time or build-time dependency of lxde components. It can contains; 1. Project standard autogen.sh 2. A tool helping us generate new project (Makefiles and configure.ac) in a user-friendly, even GUI way. 3. xml-purge tool used to optimize the sizes of glade files. 4. Script used to check and fix errors like missing \n in translations. 5. A tool used to check gtk+ API versions. In gtk+ API doc, they provided lists of new symbols in each releases. We can get those symbols and grep them in our source code to determine minimal gtk+ or glib version. So we can set it properly in configure.ac. 6. A release gate-keeper script running some automated checks such as make dist; tar; configure; make all to make sure the tarball builds, to run checkers for translation, and others. This test tool should be run prior to any tarball release.
Then, make all of these tools included in one lxde-devel package.Then developers can get it installed for use in lxde development. It's just a proposal. I myself don't know how to write these scripts since I'm no shell script guru, but I'm sure it's possible. Regarding to release process, I agree with all of you for setting up a release team. For alpha or beta release I think there shouldn't be restrictions since the purpose of alpha or beta release is for helping development. However stable release must be made by release team after QA only. Developers drop mails in the mailing list when new release is suitable and release/QA team make the release after proper testing. Developers should tag the release properly in git and ask the release/QA team to test against git code with that tag. Any comments? On Tue, Apr 6, 2010 at 11:34 PM, Martin Bagge / brother <[email protected]> wrote: > On Tue, 6 Apr 2010, Marty Jack wrote: > >> Is there some sort of automated tool we could run to catch this \n mismatch >> error? It seems to come up quite frequently; and since we are taking >> translations automatically, it can happen on any checkin. Most often it >> happens on the "Translator Credit" strings. It would be nice if git builds >> all the time, not just when we do a release. > > To just get the complete picture of the state of the translations I run > intltool-update -m > intltool-update -r > in the po directory. > > The -m > This will scan for files with translatable content in the source and match > those to the files in POTFILES.in, if missing they will be in STDOUT and a > file called missing and could be added to POTFILES.in. > > The -r > This will resync all po files present with the pot file. Adding new > removing obsolete and marking updated strings as fuzzy ("review" needed). > > If a file is not well formed (missing a \n in msgstr where there was a \n > in msgid for instance) a error will be raised. It checks for other errors > too. > The -r will however touch ALL files and bump the created timestamp and > should not be used if no changes are present, see below for automated > things. > > The tools to use! > msgfmt or msgcat can be used to check the files. > msgfmt -c file.po > This will do the checks and outout the status in STDOUT. > If none, continue with next step. If any correct the issue. > > A common notion is to use > msgcat file.po > file.po_copy > this will do checks and wrap lines at 80 and so on. The output is in > STDOUT so when without errors just catch it and direct it to the original > file). > > > For the translators using Pootle ALOT of error and quality checking is > hidden under "review" in the interface. It check for missing symbols, new > lines, acronyms and such things. The review tool is really easy to use and > would ramp things alot if people could use it. I plan to write guides for > these in the future but trying them out won't hurt abit. > > > -- > brother > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Lxde-list mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/lxde-list > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Lxde-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxde-list
