On 2 June 2010 01:37, Lucas Rocha <[email protected]> wrote: > Hi all, > > The release team would like to propose some important changes in the way we > organize our modulesets. > SNIP > Comments, ideas, and suggestions are welcome.
Hi Lucas and Releases Team! Wow lenghty thread, but most interesting read! Generally I am all for a restructuring of the way we think about modules and the initial proposal sounds mostly like what I'd suggest myself. I can however easily follow the worry of application developers for loosing the Apps module, and to lesser (but still some) extend the trouble for the distributors for selecting the right apps to distribute. I think that an apps module still makes sense, but in a revised form, because the current one has worried me deeply for a few years now. Here follows my proposal for a revised Applications module. Firstly let's consider what and optimal solution would be: * Promoting the best, but also make good alternative noticeable * Consist only of high quality apps of all sorts * Be open to anything with sufficient quality * Easy participation for spare time contributors of all sorts * Easy participation for companies and professional contributors * Reliable delivery for vendors * Entice/reward developers to produce better apps Here are the some of the features of the current approach that I believe ultimately works against these goals (even though they may have other merits): * Enforced hosting * Enforced VCS * "One appp per task" ie. not both Rhythmbox and Banshee * Apps that are too specialized do not have a place My proposal is to let us inspire by the Apache Incubator idea[1], making app inclusion a two stage process. Mature in the Gnome Incubator and then when the project is mature and well maintained it gets the honour of graduating into the Gnome Application Portfolio. It's important to note that we should be able to have several competing apps in both incubator and in the portfolio. It might not be a good idea to have 10 music players, but 3 or 4 should not be a problem. Distributors and contributors alike can make their own choices and pick their favourite(s). So I call it "portfolio" because it's not a "module" where we expect distributors to ship everything, but a collection of blessed top notch stuff. GNOME INCUBATOR Getting into Gnome Incubator is not a freebie. Stuff in the incubator is something that we expect will seriously contend for inclusion in the portfolio some day. Being in the incubator should be enough of a QA stamp that it attracts some mindshare - reviews, patches, i18n, a11y, etc (the marketing team can help with showcasing and such). Its a badge of honour. Here are a few suggestions that could be points to assess when deciding whether something should have the honour of going into incubator: * Project age (many projects die early on after a few months) * Size of codebase (two .py files in a tarball is not enough) * Number of contributors * Code quality * Activity/project healthiness * How many similar projects are in incubation/portfolio Note that incubator has *no* requirements for build system, dependencies, i18n, a11y, autofoo, help docs, HIG compliance, hosting, being generally useful (specialist apps are ok), or anything. It does imply that we expect that these qualities develop over time though, helped also by the added attention the incubation will bring. Unmaintained projects or projects with unfixable problems (fx. political or social) can be removed from the incubator by the release team. Generally I'd expect projects to be incubating from 6 months up to a few years. GNOME APPLICATION PORTFOLIO When an application has been in incubation and has reached maturity the maintainers, or the Gnome release team, can propose it for graduation into the portfolio, the highest honour we can attribute to a project. In addition to the points evaluated for the incubator (leaving out the last one about similar projects) the following points should be considered when evaluating a project for joining the portfolio: * i18n, l10n * a11y * help docs * Build system must be autotools * Integration * HIG compliance * Using only blessed deps * Project hosting (and VCS) is on a list of approved sites TRANSITION FROM GNOME 2 I'd propose that all apps in the Application Module (that want to) can go directly into the Gnome Application Portfolio. At their discretion of the maintainers they can go into incubator - which might actually make sense if the project wants some motivation and review. BONUS We could consider applying the same methodology for Desktop, (Extended) Platform, and Mobile. It's not as good a match as the apps are in my eyes though. I believe that this structure would address all of the bullet points in the start of this very long email. Thanks for staying with me so long! Cheers, Mikkel [1]: http://apache.org/foundation/how-it-works.html#incubator _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
