ahoj, Am Montag, den 19.02.2007, 13:58 +0100 schrieb Vincent Untz: > First, let me tell you I love you. flights from prague to grenoble are cheap, always keep that in mind, ma petite fleur! ;-) > > * \I18n: "POTFILES.in and POTFILES.skip are updated regularly." > This one is hard, since there are always issues, even with the current > modules. you're right. changed it to: "POTFILES.in and POTFILES.skip should be updated regularly." i think "should" is appropriate, is that okay? > + we should mention that maintainers should be subscribed to > devel-announce-list and aware of the schedule > (linking to http://live.gnome.org/MaintainersCorner shouldn't harm) > + dependencies of proposed modules should be clearly highlighted in the > proposal mail > + the part about licenses is not clear. What's a free or open license? > (I guess that it was written this way in the GEP) yeah, from the gep. it's not a clear statement at all, but i think that people get the sense behind it (= {free,libre,opensource}-software). > We should probably mention something like "in case of doubt about the > module license, send a mail to ..." where ... could be release-team > or d-d-l > + would be great to mention that the app should be added to the jhbuild > moduleset added those ones, thanks. > Also, while what's written here is true for all module proposals, the > goal of the document is about proposing modules to the > desktop/admin/devtools sets. Bindings and platform have additional > rules, see > http://live.gnome.org/ReleasePlanning/ModuleRequirements > > Note that what you wrote under Criteria could live in the module > requirements pages. Don't know what's best. me neither... but i like your idea (perhaps just because i'm totally sober at the moment), and it makes it more handy, i think. if we have module requirements, we should not have them at two different pages. okay, to summarize: PORPOSED ACTIONS: * create http://live.gnome.org/ReleasePlanning/ModulesProposing (see attachment) * extend http://live.gnome.org/ReleasePlanning/ModulesRequirements for "General Requirements" (see attachment). clearly state that there are additional rules for bindings and platform (we keep the links on that wiki page). na shledanou, andrej -- mailto:ak-47 gmx net | failed! http://www.iomc.de/ | http://blogs.gnome.org/portal/aklapper
== How to propose 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). Maintainers should take care that the proposed module gets added to the jhbuild moduleset - 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 should be subscribed to devel-announce-list and aware of the GNOME schedule at http://live.gnome.org/TwoPointSeventeen. Please read http://live.gnome.org/MaintainersCorner. * 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 of proposed modules should be clearly highlighted in the proposal mail and should be defined as soon as possible, so the Release Team can list them at http://live.gnome.org/TwoPointSeventeen/ExternalDependencies. 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. * Carefully read the Proposal Criteria and Module Requirements at http://live.gnome.org/ReleasePlanning/ModuleRequirements. == 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.
== General Module Requirements (for all proposals) == * 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. In case of doubt about the module license, send an email to the Release Team and the desktop-devel mailing list. 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 should be 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. == Further ressources == 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