From Fedora Project Wiki
(Updated! Glad to see so many objectives being successfully completed!) |
m (Deprecation category and notice. This page will not be deleted.) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{Deprecated}} | |||
= Plans = | = Plans = | ||
| Line 13: | Line 14: | ||
* OK - Announce (Fedora and lwn/foo) | * OK - Announce (Fedora and lwn/foo) | ||
* OK - Make sure statistics and every piece of the puzzle works | * OK - Make sure statistics and every piece of the puzzle works | ||
* OK - Mass-email elvis users to create Fedora accounts (/L10N/Join page is ready) | |||
* OK - IRC for help in registration process (sign CLA etc) | |||
Others: | |||
* CANTFIX (no resources) - Migrate users from elvis | * CANTFIX (no resources) - Migrate users from elvis | ||
=== Priority 2 === | === Priority 2 === | ||
| Line 23: | Line 26: | ||
* OK in v05 - For every commit, new module (or edit), notify related people | * OK in v05 - For every commit, new module (or edit), notify related people | ||
* OK in v05 - Expose public parts as RSS too | * OK in v05 - Expose public parts as RSS too | ||
* OK - Enable all projects in Transifex | * OK - Enable all projects in Transifex | ||
* OK - Contact hosted.fpo-hosted developers to add their project too (eg. opyum) | * OK - Contact hosted.fpo-hosted developers to add their project too (eg. opyum) | ||
* OK - Communicate with rest of elvis devs and urge them to move to Fedora infra | * OK - Communicate with rest of elvis devs and urge them to move to Fedora infra | ||
* OK - Enable Tx on both app servers | * OK - Enable Tx on both app servers | ||
* OK in v05 - Add possibility to set flag with Tx (hold/release a package) | * OK in v05 - Add possibility to set flag with Tx (hold/release a package) | ||
| Line 38: | Line 39: | ||
* OK in v05 - Code high-level views for maintenance | * OK in v05 - Code high-level views for maintenance | ||
* OK in v05 - Big table with registered modules, releases, branches | * OK in v05 - Big table with registered modules, releases, branches | ||
* OK in v05 - DL: Keep in sync with upstream, convince them to do releases | * OK in v05 - DL: Keep in sync with upstream, convince them to do releases | ||
* OK in v05 - Move DL SQLite to mysql, have one app server to update the DB and the rest just their caches | * OK in v05 - Move DL SQLite to mysql, have one app server to update the DB and the rest just their caches | ||
* OK in v05 - Configure DL to get notifications for each commit from each VCS (probably via Tx) and update LIVE the module's statistics, instead of running the cron job every a few hours. | * OK in v05 - Configure DL to get notifications for each commit from each VCS (probably via Tx) and update LIVE the module's statistics, instead of running the cron job every a few hours. | ||
* OK in v05 - Separate Tx commit mechanism from web app to a separate process/service. (big project) Benefits: Increased security (apache no access to the SSH keys), enable an upstream project to actually do the commit/push, Tx only requests the commits (good for GNOME, KDE, etc) | |||
* OK in v05 - Increase verbosity in tools: Add more links and common info in both DL+Tx (eg. mention on the top of each page how to checkout and where from to checkin respectively, links to bugzilla and maintainers, etc). | |||
Others: | |||
* | * Same table for Tx but also test write access for each module/branch | ||
* SSH key overview/administration (admins) | |||
* CANTFIX (no resources) - DL+Tx: Make sure all branches/modules are there, all the time. This applies for all registered super-projects (Fedora, RHEL, CentOS, OLPC) | |||
=== Priority 2 === | === Priority 2 === | ||
| Line 58: | Line 57: | ||
* OK in v05 - Give them the ability to add a new branch to their module | * OK in v05 - Give them the ability to add a new branch to their module | ||
* OK - Give Transifex access directly through the FAS (reduced overhead on Fedora Infra) | * OK - Give Transifex access directly through the FAS (reduced overhead on Fedora Infra) | ||
* OK in v05 - Build RPM for DL and push DL+Tx RPMs in Fedora Universe | * OK in v05 - Build RPM for DL and push DL+Tx RPMs in Fedora Universe | ||
* OK in v05 - Build a common model/configuration with DL (maintenance cost down). | * OK in v05 - Build a common model/configuration with DL (maintenance cost down). | ||
* OK in v05 - Create similar models to DL in Tx. Experiment in running DL scripts to populate them. Goal: Not having to maintain two separate Views, configuration files, checked-out caches. | * OK in v05 - Create similar models to DL in Tx. Experiment in running DL scripts to populate them. Goal: Not having to maintain two separate Views, configuration files, checked-out caches. | ||
Others: | |||
* WONTFIX (we have a better solution with intermediate repos) - Expose repos: Give developers the ability to pull translations instead of having Tx push them | |||
| Line 70: | Line 69: | ||
=== Priority 1 === | === Priority 1 === | ||
* OK (could need some more love) - Get in touch with RH Docs to see if they could work closer with the community and leverage its throughput | |||
* OK in v05 - Test OpenID | |||
* OK in v05 - Make Tx *completely* portable to any independent project that wants its resources localized | |||
Others: | |||
* Planned: Implement VCS-agnostic CLI client to work independantly of the web interface (big project). Eg. <code>tx checkout --all</code> and <code>tx submit <proj> <branch> <file></code> | * Planned: Implement VCS-agnostic CLI client to work independantly of the web interface (big project). Eg. <code>tx checkout --all</code> and <code>tx submit <proj> <branch> <file></code> | ||
* Maybe someday: Could get integrated with kbabel, gtranslator, etc. | * Maybe someday: Could get integrated with kbabel, gtranslator, etc. | ||
* Planned: Pootle: Make it work with Transifex. See what is/isn't needed and customize accordingly. | * Planned: Pootle: Make it work with Transifex. See what is/isn't needed and customize accordingly. | ||
* CANTFIX (no resources) - Install a test instance, even without Tx for specspo | * CANTFIX (no resources) - Install a test instance, even without Tx for specspo | ||
* No feedback: Why not have the docs in some "unofficially supported" languages too? | |||
* No feedback | |||
* Discuss with Debian community their needs and requirements | * Discuss with Debian community their needs and requirements | ||
=== Priority 2 === | === Priority 2 === | ||
* OK in v05 - Add ability to "hold" and "release" a project/branch, like in elvis | * OK in v05 - Add ability to "hold" and "release" a project/branch, like in elvis | ||
* OK - Start thinking big | * OK - Start thinking big | ||
* OK in v05 - Have language-specific and project-specific sub-domains, specific content for each | * OK in v05 - Have language-specific and project-specific sub-domains, specific content for each | ||
* Planned: Fine-grain permissions in Tx: Language maintainers, approvals by proj/lang/branch, etc. Who owns what, who controls what. | |||
== Community == | == Community == | ||
* OK - Send emails to -announce before every release | |||
Others: | |||
* Continue building groups, mailing lists, the community | * Continue building groups, mailing lists, the community | ||
* Work better together with Ambassadors -- look at Ubuntu for "loco teams" | * Work better together with Ambassadors -- look at Ubuntu for "loco teams" | ||
* Give credits in all Fedora-is-upstream applications/docs | * Give credits in all Fedora-is-upstream applications/docs | ||
* Bi-weekly meetings | * Bi-weekly meetings | ||
| Line 110: | Line 108: | ||
* Docs in general! LTSP? Manpages? | * Docs in general! LTSP? Manpages? | ||
[[Category:Localization]] | [[Category:Localization]][[Category:Deprecated]] | ||
Latest revision as of 18:55, 25 June 2009
This page is outdated and is only retained for historical reference
Plans
Here are some detailed plans on what we can do in the localization landscape. Maybe "ideas" is a better word. Mostly ideas specific to tools, gathered in mailing lists and at FOSS.in when a bunch of translators and developers gathered around.
These aren't official plans of the FLP, just a bunch of useful notes and food for thought.
Correct what's not working (fix)
Priority 1
- OK - Put Transifex into production at translate.fpo (100% complete)
- OK - Add missing modules & branches, do some final checks
- OK - Announce (Fedora and lwn/foo)
- OK - Make sure statistics and every piece of the puzzle works
- OK - Mass-email elvis users to create Fedora accounts (/L10N/Join page is ready)
- OK - IRC for help in registration process (sign CLA etc)
Others:
- CANTFIX (no resources) - Migrate users from elvis
Priority 2
- OK in v05 - Add email notifications
- OK in v05 - For every commit, new module (or edit), notify related people
- OK in v05 - Expose public parts as RSS too
- OK - Enable all projects in Transifex
- OK - Contact hosted.fpo-hosted developers to add their project too (eg. opyum)
- OK - Communicate with rest of elvis devs and urge them to move to Fedora infra
- OK - Enable Tx on both app servers
- OK in v05 - Add possibility to set flag with Tx (hold/release a package)
Increase efficiency (enhance)
Priority 1
- OK in v05 - Code high-level views for maintenance
- OK in v05 - Big table with registered modules, releases, branches
- OK in v05 - DL: Keep in sync with upstream, convince them to do releases
- OK in v05 - Move DL SQLite to mysql, have one app server to update the DB and the rest just their caches
- OK in v05 - Configure DL to get notifications for each commit from each VCS (probably via Tx) and update LIVE the module's statistics, instead of running the cron job every a few hours.
- OK in v05 - Separate Tx commit mechanism from web app to a separate process/service. (big project) Benefits: Increased security (apache no access to the SSH keys), enable an upstream project to actually do the commit/push, Tx only requests the commits (good for GNOME, KDE, etc)
- OK in v05 - Increase verbosity in tools: Add more links and common info in both DL+Tx (eg. mention on the top of each page how to checkout and where from to checkin respectively, links to bugzilla and maintainers, etc).
Others:
- Same table for Tx but also test write access for each module/branch
- SSH key overview/administration (admins)
- CANTFIX (no resources) - DL+Tx: Make sure all branches/modules are there, all the time. This applies for all registered super-projects (Fedora, RHEL, CentOS, OLPC)
Priority 2
- OK in v05 - Give more control to developers directly
- OK in v05 - Add web-based interface for developers to register their projects
- OK in v05 - Give them the ability to add a new branch to their module
- OK - Give Transifex access directly through the FAS (reduced overhead on Fedora Infra)
- OK in v05 - Build RPM for DL and push DL+Tx RPMs in Fedora Universe
- OK in v05 - Build a common model/configuration with DL (maintenance cost down).
- OK in v05 - Create similar models to DL in Tx. Experiment in running DL scripts to populate them. Goal: Not having to maintain two separate Views, configuration files, checked-out caches.
Others:
- WONTFIX (we have a better solution with intermediate repos) - Expose repos: Give developers the ability to pull translations instead of having Tx push them
Add functionality (extend)
Priority 1
- OK (could need some more love) - Get in touch with RH Docs to see if they could work closer with the community and leverage its throughput
- OK in v05 - Test OpenID
- OK in v05 - Make Tx *completely* portable to any independent project that wants its resources localized
Others:
- Planned: Implement VCS-agnostic CLI client to work independantly of the web interface (big project). Eg.
tx checkout --allandtx submit <proj> <branch> <file> - Maybe someday: Could get integrated with kbabel, gtranslator, etc.
- Planned: Pootle: Make it work with Transifex. See what is/isn't needed and customize accordingly.
- CANTFIX (no resources) - Install a test instance, even without Tx for specspo
- No feedback: Why not have the docs in some "unofficially supported" languages too?
- Discuss with Debian community their needs and requirements
Priority 2
- OK in v05 - Add ability to "hold" and "release" a project/branch, like in elvis
- OK - Start thinking big
- OK in v05 - Have language-specific and project-specific sub-domains, specific content for each
- Planned: Fine-grain permissions in Tx: Language maintainers, approvals by proj/lang/branch, etc. Who owns what, who controls what.
Community
- OK - Send emails to -announce before every release
Others:
- Continue building groups, mailing lists, the community
- Work better together with Ambassadors -- look at Ubuntu for "loco teams"
- Give credits in all Fedora-is-upstream applications/docs
- Bi-weekly meetings
- Split specspo in chunks of reduced priority.
- Also, make it work with rpm (spot)
Other ideas worth considering
- JBOSS Docs, similar to RH Docs
- Docs in general! LTSP? Manpages?