ahoj, Am Mittwoch, den 31.01.2007, 23:23 -0700 schrieb Elijah Newren: > On 1/30/07, Vincent Untz <vuntz gnome org> wrote: > > Stupid question: do we have a webpage explaining how to do this? > http://developer.gnome.org/gep/gep-10.html > http://mail.gnome.org/archives/devel-announce-list/2006-April/msg00000.html > but neither really focus on the 'how' of it, e.g. mentioning that > proposals are done by emailing d-d-l. It'd be nice to add that info > and combine information from these documents onto a wiki page and link > to it from our release schedule. If I wait long enough, I'm sure > someone else will do it. ;-) dumdidum... i've attached a proposal for this (live.gnome.org is down, sorry). i propose http://live.gnome.org/ReleasePlanning/ModulesProposing as URL. basically, i've mashed up those two documents and added the following changes: additional info: * propose inclusion *to d-d-l* * only *maintainers* should propose modules * propose module dependencies to r-t i've also added additional "should" and "must" criteria that i'd like to see accepted (explicitly announcing them here before somebody accuses me of slipping them in ;-): * "Early proposing also improves the chance to already have a good number of string and doc translations when the final module decisions take place. If no documentation exists, maintainers should make an effort to work with members of the Gnome Documentation Project (gnome-doc list) to make docs happen." * \Quality: "The developers care about bug reports in bugzilla.gnome.org." * \I18n: "POTFILES.in and POTFILES.skip are updated regularly." * \Documentation: "Documentation of new modules must use gnome-doc-utils so it can be easily translated." once this is accepted and up, i will link to it in the next schedule (the next schedule is a different topic that i will come up with once i'm done with writing down the changes that i want to see.) cheers, that czech guy -- mailto:ak-47 gmx net | failed! http://www.iomc.de/ | http://blogs.gnome.org/portal/aklapper
== Procedure for proposing modules for inclusion in GNOME == * All modules should be proposed by the module maintainers (not by any other people) to the GNOME desktop-devel mailing list BEFORE the first unstable release (e.g. 2.19.1, 2.21.1). For example, the author of a new module proposing some great new service should push other maintainers to use the new service where it makes sense (by at least raising awareness on the issue, opening bugs, and if possible also making patches). It should be easy to build the modules (JHBuild and GARNOME). Early proposing also improves the chance to already have a good number of string and doc translations when the final module decisions take place. If no documentation exists, maintainers should make an effort to work with members of the Gnome Documentation Project (gnome-doc list) to make docs happen. * Maintainers of proposed modules should make sure their modules are listed in the relevant wiki pages (for example, 2.17 desktop suite page: http://live.gnome.org/TwoPointSeventeen/Desktop) with all the details (module name, link to svn, branch to use in svn, maintainers names, etc.) * Dependencies for features should be added as soon as possible by proposing them to the release-team mailing list. There are three possibilities for dependencies: make them optional, bless them as external or include them in one of our suites. New dependencies should be known before feature freezes. A dependency can be proposed for inclusion AFTER the first unstable release because it might need more time to be ready. == Proposal Criteria == * Progress on a regular basis: Modules should show a steady progress throughout the release cycle. Module owners should show they can hit release deadlines and towards the end concentrate on stabilization over feature addition. Maintainers must be able to maintain regular releases in sync with the rest of the desktop. * Improving overall desktop usability: New applications should make the GNOME Desktop a more useful place to hack, work, and play in. That might include, for example, better feature parity with other desktops, cool new things other desktops don't have, feature upgrades from older GNOME versions, or better opportunities for integration with other GNOME applications. The goal is not to include every gtk2 application available, but to include the highest quality applications that will make us competitive and which offer a stable platform for improvement and integration going forward. * Developer attitude: Lead hackers of new applications have to be willing to work with other teams, including UI, a11y, etc. We want to have a community committed to working together towards building the best possible desktop - where best is not just 'coolest' and 'most powerful' but also 'most usable' and 'most accessible.' That definitely means flexibility and compromise are important, both for maintainers and team members. * GNOME-ness: Apps must use gtk2 and other GNOME2 technologies, and have a GNOME look and feel. Deprecated parts of the platform (like gnome-config) have to be avoided, in favor of GNOME2 technologies (like gconf.) Glade should be used whenever possible to aid in a11y and i18n work. The GNOME2 porting guide [ http://developer.gnome.org/dotplan/porting/ ] has more details on making an app a GNOME2 app. * Free-ness: Apps must be under a Free or Open license and support open standards and protocols. Support of proprietary protocols and closed standards is part of the world we live in, but all applications that support closed protocols should also support open equivalents where those exist, and should default to those if at all possible while still serving their intended purpose. * Dependencies: Whenever possible, a new application should not introduce new dependencies into the GNOME build. If new dependencies are necessary, the dependencies must be generally sane. Currently 'sanity' here is defined by commentary/acceptance of the release team. * Quality: The app has basically no repeatable/repeated known crashers. Major features/buttons/options/etc. work or are removed. The developers are working to fix other bugs at a reasonable rate. The developers care about bug reports in bugzilla.gnome.org. * UI: The hackers should cooperate as much as possible with the UI team to improve the general usability of the app. This might be expected to minimally include (but is certainly not limited to) UI issues like GNOME look and feel, HIG compliance, careful choice of default settings, and clean interface design. * Accessibility: The app is compliant with a11y documentation to as great an extent as possible, and the maintainers have made good faith efforts to fix all a11y bugs filed in a timely manner by the a11y team. * Internationalization: All text is i18n-ized. POTFILES.in and POTFILES.skip are updated regularly. In addition, all reasonable steps have been taken to localize other parts of the application that might be region-dependent, like temperatures, times, etc. * Use of GNOME resources: The app should use GNOME SVN. Possible reasons to not use it include (but are not limited to) library with intents towards usage by both GNOME and KDE and concerns with the speed of GNOME anonsvn. Using other GNOME resources, like GNOME FTP and bugzilla.gnome.org, is also encouraged. * Documentation: Maintainers must be willing to work with the docs team, making sure that docs are accessible through help buttons and build properly during the build process. Documentation of new modules must use gnome-doc-utils so it can be easily translated. == Decision making == * A few weeks before module freeze, the proposed modules are discussed at desktop-devel list in order to get community input. * A few days before module freeze, the Release Team meets about new module decisions with community input. * After that, the Release Team will announce the final module decisions to devel-announce list. == Further information == http://developer.gnome.org/gep/gep-10.html http://mail.gnome.org/archives/devel-announce-list/2006-April/msg00000.html
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil