Re: Modulesets Reorganization
Am 02.06.2010 02:37, schrieb Lucas Rocha: Hi all, The release team would like to propose some important changes in the way we organize our modulesets. GNOME releases are currently organized into the following modulesets: Desktop, Platform, Bindings, Mobile, Admin, and Dev Tools. This model has served us well and has actually evolved through time - we didn't have the Admin and Dev Tools modulesets initially. However, we feel that this organization is reaching its limits, and we have explored several potential changes. snip In summary, this means that the GNOME releases would be composed by the following modulesets: - Desktop - Platform - Extended Platform - Mobile A bit late reply from my side .. I find the Mobile module set a bit out of place. In this regard I like the MeeGo approach [1]. Like having a common foundation, but separate User Experiences (UX) on top of it. This way we could have: Applications Desktop | Netbook | Mobile | ... Platform | Extended Platform The application module would be what has been suggested by some people in the thread. Stefan [1] http://meego.com/developers/meego-architecture ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Hi! The idea for the future is that we would like to change the vision people have of epiphany. Some time ago we decided to switch our engine and work on replacing gecko with a native port of webkit for our platform. Saying that this is hard work would be an understatement, but thanks to the work of many people and companies, including a tremendous effort by the one I work for, I think we are doing great progress in bringing this new crazy thing we call the web to our platform in a way that does not feel alien to it. I see your point here and that was one of the reasons it put the unsure in front of the comment about epiphany. If we create a user-experience inside GNOME 3.0 with integrated web-browsing that rocks we very well should include it. Is there some kind of RoadMap for this or concrete plans? A quick look at the wiki didn't reveal anything. Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Hi! OK, as the discussion calmed down a bit I wanted to make some more constructive comment to the new module organization. I feel that there are a couple of (utility) applications that should be part of GNOME (e.g. the Desktop module set). This is a subset of the current application in the Desktop module even if they are not necessary for getting the session up. I left out the things that are necessary to start the session and I also left out accessibility but simply because I have nearly no idea about those modules. Someone should add those please. * bug-buddy (the point is that most distros don't use it so maybe we should remove it) * evince * eog * file-roller * gcalctool * gedit * gnome-terminal * nautilus * seahorse * totem * yelp These are the minimal requirements I see for a desktop computer to have, whatever the purpose of this computer is. These should probably also integrated tightly into the desktop so that the user doesn't even see them as real applications. In addition I would propose to have an Applications module where modules are included that are * Hosted on gnome.org (git, translations, etc.) * Follow the rules here http://live.gnome.org/ReleasePlanning/ModuleProposing * Have an UI, documentation and accessibility review if possible It might be a good idea to create some subcategories here like Online (evo, empathy, epiphany), Multimedia (rhythmbox, etc.), DevTools, Photos, Utilities (hamster, etc.). This list should be reviewed before every release and old and unmaintained stuff should drop out while new stuff can go it. It would be OK to have more than one application for the same purpose. The Applications set should be rather strict in the requirements. Better keep it small and good, but it would be a great place to promote high-quality applications and not as abstract as some promotion on the web site. Just my 2 cents, Johannes P.S: Background of my proposal for specific things that may look strage at first sight (some examples): * evolution: Many people just use webmail * epiphany: unsure. Most distros ship firefox. A webbrowser is definitly a requirement so. * sound-juicer/brasero: I had them on the list and realized then that there are many devices without an optical drive. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Hi all! Other GNOME translators have already commented on this proposal, but I thought I'd share some of my views from the i18n/l10n point of view anyway. Michael Terry m...@mterry.name, Wed, 2 Jun 2010 08:54:49 -0400: On 1 June 2010 19:37, Lucas Rocha luc...@gnome.org wrote: 3. We strongly believe that we should encourage a strong ecosystem of apps around GNOME, and integrating all applications in the GNOME Desktop moduleset is not the best way to achieve this. As the maintainer of Déjà Dup, I approve of this move. I feel Déjà Dup is a bit of a poster child for this change. Please note that the said proposal would very likely affect the l10n processes for many modules in a rather negative way. In particular, not providing (or not being required to do so) the translators a possibility for a sufficiently long string freeze period means that they aren't able and motivated to work on completing the l10n task before the module release. So I think, since i18n and l10n have long been core values for the GNOME Project, that having a clear release schedule and string freeze period shouldn't be just appreciated encouraged from GNOME module maintainers, but simply required in order to ensure that GNOME l10n in a variety of languages is complete, consistent, and of reasonable quality. Furthermore, GNOME maintainers should always enable translators from the GNOME Translation Project (only) to work on module l10n using GTP in-house infrastructure. Adhering to other l10n projects or infrastructures goes against the fact that not other l10n project, but the GTP is and has been responsible for how the GNOME software is localized. The way how code development works is often confused with how l10n works, but these processes are different. For a working l10n effort, it's often quite more important to make use of centralized, normative infrastructure for a set of software projects that are to be localized with standardized team work flow, task planning, providing and sharing best practices, incl. sufficient consistency in translation terminology, style, etc. This all can be hardly accomplished when you have to deal with zillions of different l10n platforms, teams, release schedules and so on. In other words, working on GNOME translations should mean working within one translation project, with one language team, on one platform. So as I'm quite concerned over the future of the GNOME l10n efforts, it's my hope that the reorganization proposal won't be approved in its current form. Thanks, Petr Kovar ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
2010/6/6 Tomeu Vizoso tomeu.viz...@collabora.co.uk: On Wed, Jun 2, 2010 at 01:37, Lucas Rocha luc...@gnome.org wrote: Presently, we have this stub for what is considered as bindable: http://live.gnome.org/GObjectIntrospection/WritingBindingableAPIs Thanks a lot for that info. Just added a note about that in http://live.gnome.org/GTK+/BestPractices Regards, -- Javier Jardón Cabezas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Le dimanche 06 juin 2010 à 19:53 +0200, Tomeu Vizoso a écrit : Moving bindings modules to the Desktop moduleset won't make them less second-class citizens as long as API that is not bindable without resorting to language-specific glue code keeps being added to Platform. Examples of this are GVariant (which affects GSettings) and GDBus, in the latter this question was raised on gtk-devel but nobody showed interest in how to make the new functionality available to bindings: http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00136.html I don't think the authors of those APIs are to blame for this, because they asked for feedback before merging and nobody who cared about non-C languages replied. It's nice that the release team worries about bindings because lots of software is written for GNOME in languages other than C. But today we are seeing a disproportion between the people who use bindings and those that build them and it worries me a lot. What will happen to those applications when old APIs such as GConf are not available any more and GSettings is not available to their language? An action more in accordance with the intention of making bindings a first class citizen would be to require new API (with exceptions for low level glib stuff) to be bindable by the introspecting bindings, and also maybe some thinking into why the bindings landscape is in such a mess right now. While I agree with you case about the importance of bindings, I don't see why GSettings shouldn't work with bindings. For GNOME Shell, we had a few issues with g_settings_get_strv() and g_settings_set_strv(), but the API was quickly improved, and now GObject introspection allows us to use GSettings from JavaScript via GJS without any flaw. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Sun, Jun 6, 2010 at 21:57, Milan Bouchet-Valat nalimi...@club.fr wrote: Le dimanche 06 juin 2010 à 19:53 +0200, Tomeu Vizoso a écrit : Moving bindings modules to the Desktop moduleset won't make them less second-class citizens as long as API that is not bindable without resorting to language-specific glue code keeps being added to Platform. Examples of this are GVariant (which affects GSettings) and GDBus, in the latter this question was raised on gtk-devel but nobody showed interest in how to make the new functionality available to bindings: http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00136.html I don't think the authors of those APIs are to blame for this, because they asked for feedback before merging and nobody who cared about non-C languages replied. It's nice that the release team worries about bindings because lots of software is written for GNOME in languages other than C. But today we are seeing a disproportion between the people who use bindings and those that build them and it worries me a lot. What will happen to those applications when old APIs such as GConf are not available any more and GSettings is not available to their language? An action more in accordance with the intention of making bindings a first class citizen would be to require new API (with exceptions for low level glib stuff) to be bindable by the introspecting bindings, and also maybe some thinking into why the bindings landscape is in such a mess right now. While I agree with you case about the importance of bindings, I don't see why GSettings shouldn't work with bindings. Yes, I was referring to g_settings_get_value/g_settings_set_value which is the most general API. So while part of the functionality is available to bindings there's some that isn't. Which wouldn't be so bad if at least there was an alternative API for bindings that providing the missing functionality. Similarly, I'm sure part of the GDBus API is callable via introspection, but some isn't. For GNOME Shell, we had a few issues with g_settings_get_strv() and g_settings_set_strv(), but the API was quickly improved, and now GObject introspection allows us to use GSettings from JavaScript via GJS without any flaw. If GJS is able to call those methods right now, you may need to remove some workaround there when this patch lands: https://bugzilla.gnome.org/show_bug.cgi?id=620170 (Testing, comments and review welcome, btw) Regards, Tomeu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Sun, Jun 6, 2010 at 8:55 PM, Johannes Schmid j...@jsschmid.de wrote: Hi! (...) Hey, before addressing any specific point I just want to say that I pretty much agree with the spirit of the Release Team's proposal, if not with all its details, and that I'd rather see us engage in a bit of too much destructive force on our desktop in order to sharpen our vision than die of the infamous one thousand cuts of a directionless moduleset that has, probably, grown a bit more than it should have. With that being said... P.S: Background of my proposal for specific things that may look strage at first sight (some examples): * evolution: Many people just use webmail * epiphany: unsure. Most distros ship firefox. A webbrowser is definitly a requirement so. It's very much true that for a long time pretty much every distribution has shipped browsers other than epiphany as default, even when they picked gnome as their default desktop environment. Historically firefox has been this browser, and seeing recent trends I wouldn't be surprised with chromium taking its place in the future. This has made epiphany the odd duck in the eyes of many, and given that, it's not surprising at all to see proposals like the one Johannes makes. I only want to answer with two ideas, one which should be obvious but perhaps isn't, and other than hopefully looks towards a different future for epiphany. The obvious idea is that basing our decisions on what distributions do is absolutely the wrong way of doing things. There's many distributions around, and no matter what we do there will be always some that will ignore decisions that the upstream community considers core foundations of the software we work on. This is one of the bittersweet facets of free software, and there's not really a lot to be done about it. What we *can* do, though, is work as hard as we can in shaping a coherent idea that the combination of our modules form, and make it compelling enough that most people wouldn't dream of taking it apart to build something else because they would be giving their users an impoverished experience. I don't think we should be satisfied with anything less than that. The idea for the future is that we would like to change the vision people have of epiphany. Some time ago we decided to switch our engine and work on replacing gecko with a native port of webkit for our platform. Saying that this is hard work would be an understatement, but thanks to the work of many people and companies, including a tremendous effort by the one I work for, I think we are doing great progress in bringing this new crazy thing we call the web to our platform in a way that does not feel alien to it. The problem, of course, is that users don't use APIs directly, and we still have much to do in making things usable for them. If we all agree that the web is a vital part of any modern environment we must use the opportunity we have and blend epiphany with the shell and all the other parts of gnome in one indivisible unit. Let's integrate it deep into the core experience, going where no other browser can, or would dare to, go because no other browser can break the compromises needed to sort-of-work in every possible linux environment. I've always seen this as the role epiphany should play, and at least for myself I'm more than willing to go there as long as we can figure out something that we feel makes sense for us now and in the future. Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Johannes, I really like your ideas: On Sun, 2010-06-06 at 20:55 +0200, Johannes Schmid wrote: Hi! OK, as the discussion calmed down a bit I wanted to make some more constructive comment to the new module organization. I feel that there are a couple of (utility) applications that should be part of GNOME (e.g. the Desktop module set). This is a subset of the current application in the Desktop module even if they are not necessary for getting the session up. I left out the things that are necessary to start the session and I also left out accessibility but simply because I have nearly no idea about those modules. Someone should add those please. * bug-buddy (the point is that most distros don't use it so maybe we should remove it) * evince * eog * file-roller * gcalctool * gedit * gnome-terminal * nautilus * seahorse * totem * yelp These are the minimal requirements I see for a desktop computer to have, whatever the purpose of this computer is. These should probably also integrated tightly into the desktop so that the user doesn't even see them as real applications. Agreed - I think this is a really good list. In addition I would propose to have an Applications module where modules are included that are * Hosted on gnome.org (git, translations, etc.) * Follow the rules here http://live.gnome.org/ReleasePlanning/ModuleProposing * Have an UI, documentation and accessibility review if possible I also agree - I think being hosted on GNOME infrastructure is a key requirement (and I'm confused whether this is a requirement in the new module proposal from the release team). I think being hosted on GNOME infrastructure will help with documentation, translations and accessibility. It might be a good idea to create some subcategories here like Online (evo, empathy, epiphany), Multimedia (rhythmbox, etc.), DevTools, Photos, Utilities (hamster, etc.). This list should be reviewed before every release and old and unmaintained stuff should drop out while new stuff can go it. It would be OK to have more than one application for the same purpose. I really like this idea. I think it addresses some of the other concerns that have been brought up. The Applications set should be rather strict in the requirements. Better keep it small and good, but it would be a great place to promote high-quality applications and not as abstract as some promotion on the web site. Just my 2 cents, Johannes P.S: Background of my proposal for specific things that may look strage at first sight (some examples): * evolution: Many people just use webmail * epiphany: unsure. Most distros ship firefox. A webbrowser is definitly a requirement so. * sound-juicer/brasero: I had them on the list and realized then that there are many devices without an optical drive. --Paul ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, Jun 2, 2010 at 10:50 AM, Jason D. Clinton m...@jasonclinton.comwrote: On Tue, Jun 1, 2010 at 7:37 PM, Lucas Rocha luc...@gnome.org wrote: Extra Information - We're planning to do the actual reorganization of the modulesets as soon as possible during this development cycle. The idea is that GNOME 3 is released using the new modulesets. The long term plan for the GNOME applications that were removed from the Desktop, Admin and Dev Tools modulesets is to simply highlight the high-quality applications using the GNOME platform through our communication channels (release notes, website, etc). There will be no official apps anymore and no 'Applications' moduleset in the GNOME releases. The goal here is be more open with the app developer community around GNOME and to highlight all the nice things that can be created using our platform. I want to say that I am really happy about this proposal! As co-maintainer of GNOME Games, I have had to constantly turn down people whom want their game included in the distribution only to obtain the recognition that would come with that inclusion. Some of the games that have been proposed have been of a really high quality but, for example, didn't fit the language knowledge of the current maintainers. desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list I will chime in with a me too as well. Using our marketing muscle to promote good apps and to promote the communities around those apps is the way to go. I hope to see even some cool commercials on youtube GNOME channel (or whatever) with tricks and what not. sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Le mercredi 02 juin 2010 à 22:08 +0200, Mikkel Kamstrup Erlandsen a écrit : snip 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. But isn't GNOME's failure to decide on a blessed music player the reason why we now have the choice between (at least) two good ones which are mostly equivalent, instead of one excellent? The same applies to Rhythmbox vs. Banshee and GThumb vs. F-Spot vs. Shotwell vs. Solang: I suspect we may be wasting energy in largely duplicated efforts. OTOH nobody has tried duplicating Evolution, Eye of GNOME or Evince - or if they have, that's gone unnoticed, which amounts to the same. Once an application is an official module, people know they better improve it and join their efforts rather than starting their random project elsewhere; eventually we get better software. I think the idea of an incubator and an app portfolio is great for optional apps, but for *essential* applications, making a (hard) choice at some point is really important. See how Brasero has improved and integrated nicely with all the desktop where GnomeBaker and others had failed for many years. GNOME INCUBATOR snip 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 I'll second people concerned about the consistence of the infrastructure here. I guess Approved sites includes Launchpad, which I appreciate in many regards - but the whole point of defining official modules and branding their sum GNOME is to get them work together. Not only translators would have a hard time using different VCS, but developers will stay each on their module. There will eventually be a core GNOME on git.gnome.org, and second-class modules all over the place. If people aren't happy with the infrastructure, then it needs to be improved, not escaped. Anyway, for git, it's not an argument, since one can always use a bzr bridge. And one more message in this interesting-but-growing thread! ;-) Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Adding telepathy-glib to Extended Platform [Was: Modulesets Reorganization]
Le mercredi 02 juin 2010 à 00:37 +0100, Lucas Rocha a écrit : 3. Create a moduleset to hold our highly recommended libraries such GStreamer, e-d-s, and others. This moduleset will be called Extended Platform. This is very good news! What's the procedure to propose module to this new moduleset? We'd like to propose telepathy-glib which, I think, could be a good candidate: - Currently used by Empathy, Vino and Vinagre. - We are currently working on adding gobject-introspection to high level clients API. Projects such as Zeitgeist and gnome-shell plan to use it. - tp-glib is API and ABI stable: 0.odd.x has the same API guarantees as 0.even.x. - All the API is documented: http://telepathy.freedesktop.org/doc/telepathy-glib/ - 0.odd.x are development releases and we make stable release in time for GNOME stable releases. For example, Empathy 2.31.x depends on telepathy-glib 0.11.x and Empathy 2.32.0 will depends on telepathy-glib 0.12.0 Let us know what you think. Thanks! G. -- Guillaume Desmottes gdesm...@gnome.org Jabber cass...@jabber.belnet.be GPG 1024D/711E31B1 | 1B5A 1BA8 11AA F0F1 2169 E28A AC55 8671 711E 31B1 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On 3 June 2010 11:26, Milan Bouchet-Valat nalimi...@club.fr wrote: Le mercredi 02 juin 2010 à 22:08 +0200, Mikkel Kamstrup Erlandsen a écrit : snip 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. But isn't GNOME's failure to decide on a blessed music player the reason why we now have the choice between (at least) two good ones which are mostly equivalent, instead of one excellent? The same applies to Rhythmbox vs. Banshee and GThumb vs. F-Spot vs. Shotwell vs. Solang: I suspect we may be wasting energy in largely duplicated efforts. OTOH nobody has tried duplicating Evolution, Eye of GNOME or Evince - or if they have, that's gone unnoticed, which amounts to the same. Once an application is an official module, people know they better improve it and join their efforts rather than starting their random project elsewhere; eventually we get better software. I think the unexpressed core of my idea is based on the assumption that this existing model is basically flawed. No matter how hard you try to force developers towards the one true app they will always diverge and tread new ground. No matter how cool apps are some distributors and users alike will fancy alternatives. I think we should embrace this fact (and I really think that it's an empirical indisputable fact) and make the most of it. That was my idea. I think among your examples Evince is the only one you are right about. Evolution and EOG has an abundance (high quality) of alternatives. -- Cheers, Mikkel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Sorry for replying out of thread - i've been following the discussion from web. As one of the apps (project hamster) that prolly will fall out of the category, wanted to share my sentiment. Project hamster being part of GNOME means many things to me and there are many benefits: * promotion - distros are recommended to include your application in default set * i18n - there is no way hamster would have gotten the localizers in such a rapid pace as right after being included in gnome * quality - i was not the sole person looking to match gnome's quality expectations any more. * release cycle - we sure can just follow the gnome schedule instead of being required to do it - but it's like following aerobics on TV opposed to being in the gym. There is difference and there is the silliness that you might be just mimicking the actions without anybody really caring about it. * credibility as a dev - i believe that it gives you certain credibility that you might know what you are doing if your patches are constantly accepted in an application that is official part of gnome My question is - which parts will we be losing by this move? Can't be none - because then nothing's really changing, now, is it? Toms On Wed, Jun 2, 2010 at 10:08 AM, Patryk Zawadzki patrys pld-linux org wrote: The long term plan for the GNOME applications that were removed from the Desktop, Admin and Dev Tools modulesets is to simply highlight the high-quality applications using the GNOME platform through our communication channels (release notes, website, etc). There will be no official apps anymore and no 'Applications' moduleset in the GNOME releases. The goal here is be more open with the app developer community around GNOME and to highlight all the nice things that can be created using our platform. And this might do the exact opposite of what we all want it to do. Instead of sending a you are now all equal message it might communicate that you are now equally not worthy. Or just you are now on the same level even if the level of integration and sheer polish is nowhere to be compared. It will also kill the magic moment I experienced twice - once when I helped Daniel with Cheese and a second time when hacking on Hasmter with Toms. The moment that comes after weeks of mad hacking when you decide your work is finally good enough to become part of GNOME. Forgot to mention: not having a single release schedule will also make it very hard for app authors to propose, track and depend on features of the underlying platform or - even worse - features introduced in other apps. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Hallo I'm the Danish translation coordinator, and we were encouraged to chip in on this discussion, so I will ;) Most of arguments for needing a change and the proposed solution are just fine by med. But there is one point where I very much disagree. It concerns not including the extra relevant features. I don't know if they should be in the desktop module set, of if there should be one more with recommended application or something. The point is that right now someone makes a decision, about which programs are needed for a desktop experience and mature enough for GNOME to put its name on it and I think that it should continnue being that way, for the following reasons: 1. It sends a signal to the users. This is core GNOME stuff, this is where you find feature rich mature applications for your everyday use. 2. It helps us translators prioritize. 2.1.A lot of groups don't have the resouces to translate everything in the GNOME repo and that is not likely to change. So we look at damned lies and makes different cuts depending on how far we are in the work and how many resources we have. Right now we (Danish team) make the cut at (as a minimum) translation UI for everything on the release pages, for every release, and that helps us by setting a goal. 2.2 If these applications are not in any way associated with the release and hence thrown into teh myriade of extra applications (with everything that is there) then we have to decide for ourselves which applications are relavant enough, so that they should recieve out attention first. Such decisions are bound to much more errorprone than that way it is done now. 3. It will hurt quality 3.1 Many distros follow the GNOME release schedule, and there is a large overlap between that applications that we now have as part of the GNOME release and the ones the distros include. This means, that per automation, the way we (translators) prioritize in GNOME, entails that a large part the desktop users of these distros see, are already translated - giving them a better experience. 3.2 If these apps are not bound to GNOME release, end hence are not subject to GNOME release freezes, it means, first of all that all the distroes (mentioned above) that pull at the time of their release, will have a higher chance of pulling something in between applicication release or and older version, because there is not pressure to wrap up a release. Second of course, it means that if we want to translator close to release, to reduce the amount of waste, we will have way more release deadlines to keep track of, a task that is already close to impossible as it is. All in all, I don't mind pulling these apps out of desktop, but I think they should go back into a recommended apps release set. In this release set there wouldn't have to be any rules that we should only have one app per task (referring to banshee/rhythmbox). The selection should be made so it includes popular, mature apps that many people will use as a part of their normal desktop use. Saying that there should be no official applications and that we want to encurage a strong ecosystem of apps and that the only way of doing that it to make them all equal, is in my view a somewhat misguided attempt at pleasing developers, very much at the expence of the users. Many, especially new users want recommendation, even though diversity and freedom of choise is good and they probably enjoy that too, they want recommendations. Kind regards Kenneth Nielsen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Ok, since you dragged i18n inside, let me add a few of my thoughts from non strict devel side. 1. Reorganization is a must! Maybe a bit wider than proposed, but the path is right. I'd fork every moduleset to Core and Extra. - Desktop Apps Core (obviously the core, simpler apps that do the task) * - Desktop Apps Extra (banshee and rhythmbox and lalala)** - Desktop Platform Core - Desktop Platform Extra - System Platform Core - System Platform Extra + - GNOME Plugins (common plugin development environment for all GNOME apps) ** Since one of a kind in the system is the only logical idea, there are cases, where this is not the case. One failed for example is two panel nautilus view which is mistakenly identified as twin panel file management as in gnome-commander. Thou not developed enough gnome-commander is not an alternative to Nautilus, but alternative to file management, hence should be in Core. * basically guessing which one comparing banshee and rhythmbox is better is up to the user. Desktop CORE should by default use something simpler (like Exaile in this case (not on GNOME)). Users that KNOW what they want, can get banshee or rhythmbox through repos. At the moment one of this progs is installed by default, which naturally artificially rises it's popularity. This kind of popularity brings bloat ... 2. Remove projects, that are not hosted by gnome from translation stats and doc. Gstreamer might me important for numerous apps, but it is obviously not important enough for GNOME. You probably had noticed that project based on gnome git get more updates. Just try coping with TP and you'll know why! For such modules make Outside moduleset, not bound on i18n. Also remove project not getting attention for more then one year and put it in archives. 3. Desktop and Platform Core should follow release cycles, Extra should have free hands to decide whether to follow cycles or stay permanently on development. 4. Development should follow strict structural rules. For example; all i18n modules use gettext po for UI, which makes it easy to maintain. Doc section used multiple approaches (see balsa, gbrainy in empathy) Most projects use .xml (why not tettext po? to make it really compatible), but these use .page, some use .po ... 5. Start releasing stats (eg gnome stats page) about the project, developers, translations, users ... Picking one project over the other many times follows the development routine. It's also motivating. This way it is possible to categorize projects and one true apps for core and extra without the flames which one is better. 6. In Extra there should also be the projects that are proposed through distros. So gnome should be an upstream for everything that follows gnome rules. 7. An incubator is a playground for apps pulling to get to extra, Extra should follow GNOME rules and practices. 8. GNOME should use common development environment and should set common programing language and libraries. I never use a program that needs installing 200MB of deps just to make it run on mono. Thanks, Matej ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On 2 Jun 2010, at 22:04, Johannes Schmid wrote: I really support Tristan's idea of a restarted review process. This is time consuming but it is rather easy to do on the organsation and infrastructure level. It may or may not be more strict but it would also help to ensure we have some broader vision of application integration in GNOME 3.0. GEP-0, anyone...? http://developer.gnome.org/gep/gep-0.html Cheeri, Calum. -- CALUM BENSON, Interaction Designer Oracle Corporation, Ireland mailto:calum.ben...@oracle.com Solaris Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Oracle Corp. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Am Donnerstag, den 03.06.2010, 16:02 +0100 schrieb Calum Benson: http://developer.gnome.org/gep/gep-0.html ...and the guidelines that currently exist: http://live.gnome.org/ReleasePlanning/ModuleProposing andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Le 02/06/10 01:37, Lucas Rocha a écrit : In summary, this means that the GNOME releases would be composed by the following modulesets: - Desktop - Platform - Extended Platform - Mobile That seems a very good idea. There were indeed a need to get bindings on the platform, and extend the platform is a good module set for libraries that aims to be in the core platform but are not there yet (API/ABI stability reasons, etc). With that organisation I think libtelepathy-glib could already be promoted into 'Extended Platform'. It will be directly used by Empathy and Gnome-Shell at least. I also think it's used by vinagre. So this is a big +1 from me (for what I worth) :-) The long term plan for the GNOME applications that were removed from the Desktop, Admin and Dev Tools modulesets is to simply highlight the high-quality applications using the GNOME platform through our communication channels (release notes, website, etc). There will be no official apps anymore and no 'Applications' moduleset in the GNOME releases. The goal here is be more open with the app developer community around GNOME and to highlight all the nice things that can be created using our platform. I understand the difficulties to maintain an Application moduleset, and the need to extend a bit the definition to more modules, but I don't think this is the right solution. With that definition, Pidgin is as GNOME as Empathy then ?!? That means that GNOME applications could live in any VCS, on any server/infrastructure, with any licence, etc ?!? That will be a mess. Also the current (already legacy?) method to propose an application in the GNOME desktop was a good opportunity to get community feedback, get more developers involved in the projects, and fix lots of GNOMEy issues the app could have. Also that was an opportunity for the app to move to the GNOME infrastructure. I take my experience with Empathy for this, we moved it to GNOME infrastructure in preparation of proposing it into desktop, it was a pain because of SVN but we did it (with new system I would certainly not have moved it to GNOME's SVN and would have kept it in Collabora's git). Also the first time I proposed Empathy it was rejected with a good list of reasons, those got worked on and that gave goals for the next 6months. That resulted in a better app proposed the next cycle and got approved. If we remove that module proposal for the desktop, things could have been different. And my last issue with the proposal: All applications could decide their own release schedule ?!? That would be a total nightmare for distributions I think. See how GTK not following GNOME schedule proved to be a recurrent issue... See for a concrete example that could happen: During the GNOME 3.1.x dev cycle, Empathy is following the same cycle and Ubuntu decide to ship Empathy 3.1.x for their dev cycle too. Then 2 days before the GNOME 3.2.0 release, Empathy decide - since they are not really bound to any GNOME schedule anymore - to add new features to their 3.1.x unstable branch and delay the 3.2.0 stable release for 2 extra months. What is supposed to do Ubuntu for their planned stable release?? They revert to Empathy 3.0, or they delay their distro release for 2 months? So my opinion is we really still need an *official* 'Applications' moduleset, with strong requirements to get in. Though, we could make it more flexible, for example we could accept 2 applications doing the same job without deciding which one is best (rhythmbox + banshee, empathy + ekiga). After all deciding which app is best is really a distro decision and does not limit to GNOME (epiphany VS firefox). I think we should give to distro a set of applications that follows strong rules (licence, release schedule, freeze periods, infrastructure used, defined set of external dependencies, etc) then let them pick the app they like in that set. Regards, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, 2010-06-02 at 08:50 +0200, Xavier Claessens wrote: And my last issue with the proposal: All applications could decide their own release schedule ?!? This effectively leaves those applications with nobody to manage their release schedules. I don't see how that benefits the developers at all. They will gradually stop using a proper release schedule and quality will decrease. I am afraid that the release team might have forgotten what it's purpose is. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Hi! I understand the difficulties to maintain an Application moduleset, and the need to extend a bit the definition to more modules, but I don't think this is the right solution. With that definition, Pidgin is as GNOME as Empathy then ?!? That means that GNOME applications could live in any VCS, on any server/infrastructure, with any licence, etc ?!? That will be a mess. Also the current (already legacy?) method to propose an application in the GNOME desktop was a good opportunity to get community feedback, get more developers involved in the projects, and fix lots of GNOMEy issues the app could have. Also that was an opportunity for the app to move to the GNOME infrastructure. I take my experience with Empathy for this, we moved it to GNOME infrastructure in preparation of proposing it into desktop, it was a pain because of SVN but we did it (with new system I would certainly not have moved it to GNOME's SVN and would have kept it in Collabora's git). Also the first time I proposed Empathy it was rejected with a good list of reasons, those got worked on and that gave goals for the next 6months. That resulted in a better app proposed the next cycle and got approved. If we remove that module proposal for the desktop, things could have been different. And my last issue with the proposal: All applications could decide their own release schedule ?!? That would be a total nightmare for distributions I think. See how GTK not following GNOME schedule proved to be a recurrent issue... See for a concrete example that could happen: During the GNOME 3.1.x dev cycle, Empathy is following the same cycle and Ubuntu decide to ship Empathy 3.1.x for their dev cycle too. Then 2 days before the GNOME 3.2.0 release, Empathy decide - since they are not really bound to any GNOME schedule anymore - to add new features to their 3.1.x unstable branch and delay the 3.2.0 stable release for 2 extra months. What is supposed to do Ubuntu for their planned stable release?? They revert to Empathy 3.0, or they delay their distro release for 2 months? So my opinion is we really still need an *official* 'Applications' moduleset, with strong requirements to get in. Though, we could make it more flexible, for example we could accept 2 applications doing the same job without deciding which one is best (rhythmbox + banshee, empathy + ekiga). After all deciding which app is best is really a distro decision and does not limit to GNOME (epiphany VS firefox). I think we should give to distro a set of applications that follows strong rules (licence, release schedule, freeze periods, infrastructure used, defined set of external dependencies, etc) then let them pick the app they like in that set. I couldn't agree more with Xavier! Guys, have you really though that through? This will kill quite a couple of things in GNOME: - The GTP projects despite translating the core (which might in turn become obsolete over time). As GNOME applications will be hosted everywhere there is no chance for translators to do some quality review and to define some workflow. In addition, things like the String freeze will be completely obsolete. - The whole development model of freezes and stable/unstable releases - Deprecations and GnomeGoals Please, could you rethink that? Of course we can not host everything on earth and there might be exceptions for hosting code and bug-tracking to some extend (so a look at KDE doesn't make me too fond of that) but things like release schedule, translations will become a mess if they aren't centrally hosted. Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, 2010-06-02 at 08:55 +0200, Murray Cumming wrote: On Wed, 2010-06-02 at 00:37 +0100, Lucas Rocha wrote: 1. The arbitrary separation between Platform and Bindings can lead people to think that the bindings are second-class citizens while this is certainly not the case. However: a) The Platform set clearly tells the Bindings what needs to be bound. b) As long as the release team don't follow their own rules about the Bindings then the Bindings will not have the same prestige. Specific examples not mentioned here to avoid distraction. c) Throwing them all into one big module set won't make the distros any more likely to package them with the same amount of love. I agree with this. Do modulesets need to be disjoined? Otherwise Bindings could become a subset of Platform... Cheers, Simon ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, 2010-06-02 at 02:41 +0200, Vincent Untz wrote: Le mardi 01 juin 2010, à 19:11 -0500, Shaun McCance a écrit : 2) Will the Applications be something official that you have to nominate modules for and follow certain rules like our release procedures? A big part of what makes applications in the desktop so great is that they work with our translation, documentation, and other teams within our schedule. At first, yes, it will be this way. It's the way we've been working for years, so it's easier to do the first step with a process we know. That being said, one rule that, imho, we should remove is that the application is hosted on the GNOME infrastructure -- that's certainly a challenge, especially for translations. But we can't expect to host the whole world in our infrastructure :-) I think hosting the whole GNOME project on the same infrastructure has several advantages for the community: a single place to look for bugs, for code, for mailing lists, etc., and therefore fewer accounts to manage for everyone. It also ensures rather durable hosting (I have seen various projects moving as maintainers went in and out)... Cheers, Simon ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Le 02/06/10 08:50, Xavier Claessens a écrit : Also the current (already legacy?) method to propose an application in the GNOME desktop was a good opportunity to get community feedback, get more developers involved in the projects, and fix lots of GNOMEy issues the app could have. Also that was an opportunity for the app to move to the GNOME infrastructure. I take my experience with Empathy for this, we moved it to GNOME infrastructure in preparation of proposing it into desktop, it was a pain because of SVN but we did it (with new system I would certainly not have moved it to GNOME's SVN and would have kept it in Collabora's git). Also the first time I proposed Empathy it was rejected with a good list of reasons, those got worked on and that gave goals for the next 6months. That resulted in a better app proposed the next cycle and got approved. If we remove that module proposal for the desktop, things could have been different. Another example I just though, again taking my experience with Empathy: Before proposing Empathy in GNOME desktop I (as Empathy maintainer) didn't know *anything* about accessibility. Proposing Empathy the first time resulted in some issues raised about accessibility because the few people that understand that are reading ddl module proposals, and tests applications proposed. Probably Empathy still has accessibility issues, and surely I still do not understand fully what should be done for that, but at least Empathy being officially part of GNOME generated interest about its accessibility and we got contributions in form of patches, bug reports, informative discussions, etc. If Empathy was hosted on, say, launchpad, and did not got through an approval process to get in GNOME desktop, I'm sure I still wouldn't know that accessibility exists in GNOME. And Empathy is not the only example here, most app proposals ends in accessibility issues... Regards, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, Jun 2, 2010 at 10:08 AM, Patryk Zawadzki pat...@pld-linux.org wrote: The long term plan for the GNOME applications that were removed from the Desktop, Admin and Dev Tools modulesets is to simply highlight the high-quality applications using the GNOME platform through our communication channels (release notes, website, etc). There will be no official apps anymore and no 'Applications' moduleset in the GNOME releases. The goal here is be more open with the app developer community around GNOME and to highlight all the nice things that can be created using our platform. And this might do the exact opposite of what we all want it to do. Instead of sending a you are now all equal message it might communicate that you are now equally not worthy. Or just you are now on the same level even if the level of integration and sheer polish is nowhere to be compared. It will also kill the magic moment I experienced twice - once when I helped Daniel with Cheese and a second time when hacking on Hasmter with Toms. The moment that comes after weeks of mad hacking when you decide your work is finally good enough to become part of GNOME. Forgot to mention: not having a single release schedule will also make it very hard for app authors to propose, track and depend on features of the underlying platform or - even worse - features introduced in other apps. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Le mercredi 02 juin 2010, à 09:35 +0200, Simon van der Linden a écrit : On Wed, 2010-06-02 at 02:41 +0200, Vincent Untz wrote: Le mardi 01 juin 2010, à 19:11 -0500, Shaun McCance a écrit : 2) Will the Applications be something official that you have to nominate modules for and follow certain rules like our release procedures? A big part of what makes applications in the desktop so great is that they work with our translation, documentation, and other teams within our schedule. At first, yes, it will be this way. It's the way we've been working for years, so it's easier to do the first step with a process we know. That being said, one rule that, imho, we should remove is that the application is hosted on the GNOME infrastructure -- that's certainly a challenge, especially for translations. But we can't expect to host the whole world in our infrastructure :-) I think hosting the whole GNOME project on the same infrastructure has several advantages for the community: a single place to look for bugs, for code, for mailing lists, etc., and therefore fewer accounts to manage for everyone. It also ensures rather durable hosting (I have seen various projects moving as maintainers went in and out)... That's true, and we should certainly recommend to use the GNOME infrastructure. But it doesn't mean we should ignore everything else. Which is my point here. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Le mercredi 02 juin 2010, à 10:15 +0200, Patryk Zawadzki a écrit : On Wed, Jun 2, 2010 at 10:08 AM, Patryk Zawadzki pat...@pld-linux.org wrote: The long term plan for the GNOME applications that were removed from the Desktop, Admin and Dev Tools modulesets is to simply highlight the high-quality applications using the GNOME platform through our communication channels (release notes, website, etc). There will be no official apps anymore and no 'Applications' moduleset in the GNOME releases. The goal here is be more open with the app developer community around GNOME and to highlight all the nice things that can be created using our platform. And this might do the exact opposite of what we all want it to do. Instead of sending a you are now all equal message it might communicate that you are now equally not worthy. Or just you are now on the same level even if the level of integration and sheer polish is nowhere to be compared. It will also kill the magic moment I experienced twice - once when I helped Daniel with Cheese and a second time when hacking on Hasmter with Toms. The moment that comes after weeks of mad hacking when you decide your work is finally good enough to become part of GNOME. What if suddenly cheese gets promoted on the www.gnome.org frontpage? Or it's one highlight of the release notes for GNOME X.Y? Wouldn't this be a similar magic moment? And yes, we should do this for the great applications. Forgot to mention: not having a single release schedule will also make it very hard for app authors to propose, track and depend on features of the underlying platform or - even worse - features introduced in other apps. Huh. There's really a misunderstanding here. We *do* encourage people to follow our best practices, which includes following our release schedule. Take banshee: they use our release schedule. The six-months schedule won't disappear. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Mi, 2010-06-02 at 10:29 +0200, Vincent Untz wrote: Le mercredi 02 juin 2010, à 10:15 +0200, Patryk Zawadzki a écrit : On Wed, Jun 2, 2010 at 10:08 AM, Patryk Zawadzki pat...@pld-linux.org wrote: The long term plan for the GNOME applications that were removed from the Desktop, Admin and Dev Tools modulesets is to simply highlight the high-quality applications using the GNOME platform through our communication channels (release notes, website, etc). There will be no official apps anymore and no 'Applications' moduleset in the GNOME releases. The goal here is be more open with the app developer community around GNOME and to highlight all the nice things that can be created using our platform. And this might do the exact opposite of what we all want it to do. Instead of sending a you are now all equal message it might communicate that you are now equally not worthy. Or just you are now on the same level even if the level of integration and sheer polish is nowhere to be compared. It will also kill the magic moment I experienced twice - once when I helped Daniel with Cheese and a second time when hacking on Hasmter with Toms. The moment that comes after weeks of mad hacking when you decide your work is finally good enough to become part of GNOME. What if suddenly cheese gets promoted on the www.gnome.org frontpage? Or it's one highlight of the release notes for GNOME X.Y? Wouldn't this be a similar magic moment? And yes, we should do this for the great applications. this wouldnt be the same: we, and probably all desktop modules, worked very hard to accomplish all the features and requirements of the gnome inclusion. it then makes people proud when a module gets *officially* accepted and included in the gnome module set. promotion of apps can be done right now, without kicking out desktop applications. to be honest: when i install a gnome application like tomboy, gedit, cheese, ... i _know_ that this module is a good piece of software, as it is a gnome module. this is not the case with other apps you can find on the net, even if they base on gtk/gnome. Forgot to mention: not having a single release schedule will also make it very hard for app authors to propose, track and depend on features of the underlying platform or - even worse - features introduced in other apps. Huh. There's really a misunderstanding here. We *do* encourage people to follow our best practices, which includes following our release schedule. Take banshee: they use our release schedule. The six-months schedule won't disappear. Vincent -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Am Mittwoch, den 02.06.2010, 02:41 +0200 schrieb Vincent Untz: That being said, one rule that, imho, we should remove is that the application is hosted on the GNOME infrastructure -- that's certainly a challenge, especially for translations. But we can't expect to host the whole world in our infrastructure :-) I beg to differ. In my opinion this is not only a challenge, but a serious problem for the GNOME Translation Project. If there are no official core apps anymore, which are the ones a translation team should focus its work on? At the moment we call a language supported if it translates more than 80% of GNOME. If we'd use the new proposal, over which applications would the 80% be calculated? Every app? I guess that would drop quite a lot languages from the supported list. This is especially a problem for new language teams: which are the important applications they should translate first? Another problem is the no longer forced adherence to the release schedule: Regularly tarballs to test one's translations? String Freeze?! Predictive releases to coordinate the translation work? Furthermore, not forcing projects to be hosted in GNOMEs infrastructure imposes more work on the translation teams. As the coordinator of the German team I often have to explain git to newcomers. If I had to explain them additionally how to work with bzr, hg, whtevr would make my quite lengthy introductory mail even longer. Keep in mind that many translators are not as versed as the average C hacker! There is also the problem of different procedurals (that even arouses today). Translations for applications in GNOME's git can be directly committed, while the translation for NetworkManager lives in fdo and has to be put in a bug report, while some other projects are translated via the Translation Project. Please, don't increase this mess even more by allowing applications to live wherever the vcs-de-jour is! Last (bot not least!) there are some project hosting services which have their own translation work flow. Not that their translators do a bad job, but they are not necessarily into our translation guidelines. Image a GNOME 3 where some applications use an OK button while other ones use an Okay button. Thanks, Hendrik -- Hendrik Richter hendr...@gnome.org · 0xE642F2B0 · jab...@hendi.name ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On 2 June 2010 10:31, Luca Ferretti lferr...@gnome.org wrote: I.e. color management is of course really useful, but not needed to run a desktop session, isn't it? I think the argument is that it's a framework (DBus interface) that applications will be relying on, rather than a single application that you start and stop. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, 2010-06-02 at 00:37 +0100, Lucas Rocha wrote: The long term plan for the GNOME applications that were removed from the Desktop, Admin and Dev Tools modulesets is to simply highlight the high-quality applications using the GNOME platform through our communication channels (release notes, website, etc). There will be no official apps anymore and no 'Applications' moduleset in the GNOME releases. The goal here is be more open with the app developer community around GNOME and to highlight all the nice things that can be created using our platform. Personally I think the idea of giving up on having an Applications moduleset is a very unfortunate decision for multiple reasons: - first and foremost it will drive away fresh forces from gnome: most of new developers get involved in writing code for applications and feeling officially part of gnome is a determining factor in getting more involved in desktop-wide hacking, in the community mailing lists, join the foundation and so on - Cross-application hacking will slowly vanish, slowly ruining the quality and consistency of the gnome desktop. For instance until a few years back we had ui revisions for all gnome application each cycle which ensured consistency and quality... I think we should work on getting this kind of thing back (especially since gnome 3 will bring some changes to the ui!) instead this decision will make each application go its own way - QA effort will be impacted: I used to run a full jhbuild version of gnome all the time and I don't anymore and I think I am not the only one... This is a problem on its own (and something the RT should work on!), but if jhbuild build does not build a full desktop anymore (or if it takes 2 days to build because it pulls in 6 media players) we are once again moving in the wrong direction - A particular note goes to also giving up on the Dev Tools moduleset: new developers ask all the time about which tools should they use to hack on gnome, the dev tools moduleset was starting to become a decent answer to that (though I certainly wish it provided a more complete development environment and more tools were added, eg sysprof). Giving up on creating an official moduleset is a step back since we cannot say Want to hack on gnome? Here are the tools of the trade I am really sorry to say it, but this feels like the gnome chronic inability to make decisions: we are not able to pick RhythmBox or Banshee, we are not able to deal with Zeitgeist being on LaunchPad, etc... so the only decision we are able to make is to cop out on making decisions. Ciao Paolo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Le mercredi 02 juin 2010 à 00:37 +0100, Lucas Rocha a écrit : We're planning to do the actual reorganization of the modulesets as soon as possible during this development cycle. The idea is that GNOME 3 is released using the new modulesets. The long term plan for the GNOME applications that were removed from the Desktop, Admin and Dev Tools modulesets is to simply highlight the high-quality applications using the GNOME platform through our communication channels (release notes, website, etc). There will be no official apps anymore and no 'Applications' moduleset in the GNOME releases. The goal here is be more open with the app developer community around GNOME and to highlight all the nice things that can be created using our platform. I am very skeptical about this. The disappearance of the current desktop moduleset means that GNOME will stop providing a full-fledged desktop, which is what us distributors are all looking for. One of the strengths of GNOME is that you get synchronized releases for everything that makes a desktop. Not just a bunch of applications that happen to work together: a desktop. It has grown to provide integration of each application into others to constitute a unique, homogenous desktop experience. The disappearance of the desktop moduleset will crush all these efforts in an instant. Suddenly you will leave just a random number of applications that are out of sync, and this will make it very hard to integrate all of them together in a single desktop. Let me show you some figures: http://qa.debian.org/popcon.php?package=meta-gnome2 Currently 35% of registered Debian systems have gnome-core (which is very close to the new module arrangement you are proposing). 30% have gnome-desktop-environment, which is the current official moduleset, and 20% have gnome, which is the same with some extras. So roughly (only a low number of systems are registered on popcon) 15% of our GNOME users are interested in something as light as the new desktop moduleset you are proposing. And we are one of the distributions with the largest number of users interested into lightweight, customized desktops. I understand you want downstream distributors to make their own mind about what they want to distribute in their desktops. But frankly this will only reduce the amount of support and integration we are able to provide. Different distributions will be less synchronized, and without synchronization between their releases, the integration between applications is bound to lower in quality. In short, I understand you want to split the core desktop and the recommended applications. But there has to be a set of recommended applications in the official modulesets. Cheers, -- .''`. Josselin Mouette : :' : `. `' “A handshake with whitnesses is the same `- as a signed contact.” -- Jörg Schilling ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Hi, On Wed, 2010-06-02 at 10:29 +0200, Vincent Untz wrote: Le mercredi 02 juin 2010, à 10:15 +0200, Patryk Zawadzki a écrit : On Wed, Jun 2, 2010 at 10:08 AM, Patryk Zawadzki pat...@pld-linux.org wrote: The long term plan for the GNOME applications that were removed from the Desktop, Admin and Dev Tools modulesets is to simply highlight the high-quality applications using the GNOME platform through our communication channels (release notes, website, etc). There will be no official apps anymore and no 'Applications' moduleset in the GNOME releases. The goal here is be more open with the app developer community around GNOME and to highlight all the nice things that can be created using our platform. And this might do the exact opposite of what we all want it to do. Instead of sending a you are now all equal message it might communicate that you are now equally not worthy. Or just you are now on the same level even if the level of integration and sheer polish is nowhere to be compared. It will also kill the magic moment I experienced twice - once when I helped Daniel with Cheese and a second time when hacking on Hasmter with Toms. The moment that comes after weeks of mad hacking when you decide your work is finally good enough to become part of GNOME. What if suddenly cheese gets promoted on the www.gnome.org frontpage? Or it's one highlight of the release notes for GNOME X.Y? Wouldn't this be a similar magic moment? And yes, we should do this for the great applications. I think this is a key point. We talked a bit about this at the Marketing hackfest and the ability to market key applications - especially those that we think may be awesome apps that weren't part of the Desktop before - is important. End users are getting used to the idea of apps (and app stores) and while GNOME has not included a media manager in the Desktop we should be marketing Rhythmbox and Banshee or the next great one that's developed. (And gives us interesting ways to partner with downstream distributions as well). To market these apps effectively, they will need to adhere to GNOME guidelines and processes. They'll need to be free software, they'll need to be localized, they'll need documentation, they'll need to be accessible. Then, and only then, should we be marketing to them on places like GNOME.org. Forgot to mention: not having a single release schedule will also make it very hard for app authors to propose, track and depend on features of the underlying platform or - even worse - features introduced in other apps. Huh. There's really a misunderstanding here. We *do* encourage people to follow our best practices, which includes following our release schedule. Take banshee: they use our release schedule. The six-months schedule won't disappear. Vincent Speaking of Banshee - this was a pretty active conversation a few months ago within the Banshee community whether Banshee should follow the GNOME release cycle or not. I had volunteered (long ago) to write the documentation for Banshee, and once this decision was made to align with the GNOME release cycle, it was a very big motivational tool to get the documentation finished. Paul ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, 2010-06-02 at 18:14 +0800, Paul Cutler wrote: [snip] I had volunteered (long ago) to write the documentation for Banshee, and once this decision was made to align with the GNOME release cycle, it was a very big motivational tool to get the documentation finished. It's very nice when other modules choose to follow GNOME's schedule, but the commitment will never be as strong as when the release-team is making sure that they stick to it. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Hi all, Just to let you know: this is an initial proposal from the Release Team. There's nothing set in stone yet. This means we're definitely hearing all the feedback and we'll take all the ideas and counter-arguments into account when deciding on that. So, no need to get too defensive. Keep bringing the good feedback - which is what is happening now btw. --lucasr 2010/6/2 Lucas Rocha luc...@gnome.org: Hi all, The release team would like to propose some important changes in the way we organize our modulesets. GNOME releases are currently organized into the following modulesets: Desktop, Platform, Bindings, Mobile, Admin, and Dev Tools. This model has served us well and has actually evolved through time - we didn't have the Admin and Dev Tools modulesets initially. However, we feel that this organization is reaching its limits, and we have explored several potential changes. Current issues -- A set of issues makes it clear the need for an evolution here: 1. The arbitrary separation between Platform and Bindings can lead people to think that the bindings are second-class citizens while this is certainly not the case. 2. The Desktop moduleset has expanded so much that it's now unclear which type of application should go in and which shouldn't; it's also forcing us to choose one application over another, or to avoid any decision - like in the famous Rhythmbox vs Banshee case. 3. We strongly believe that we should encourage a strong ecosystem of apps around GNOME, and integrating all applications in the GNOME Desktop moduleset is not the best way to achieve this. 4. Some libraries should be used by developers even if the API/ABI guarantees are not as strong as our GNOME 2 Platform (e.g. GStreamer, e-d-s, and others). Such libraries should be labeled as such, obviously. Proposed (re)organization - With that said, the release team would like to propose the following reorganization of the modulesets: 1. The Desktop moduleset will only contain the components needed to get a desktop session running and provide core functionalities (e.g. gdm, gnome-session, gnome-settings-daemon, nautilus, etc). All applications providing extra relevant features to the desktop (e.g. gedit, Totem, Tomboy, etc) will be moved out from the Desktop moduleset. See the Extra Information section for more details. 2. Bindings will be merged into the Platform moduleset and become first-class citizens on the development Platform. The goal is to make the bindings more prominent from a communication perspective. 3. Create a moduleset to hold our highly recommended libraries such GStreamer, e-d-s, and others. This moduleset will be called Extended Platform. 4. Admin and Dev Tools will be dissolved and will be promoted like any other GNOME application. See the Extra Information section for more details. In summary, this means that the GNOME releases would be composed by the following modulesets: - Desktop - Platform - Extended Platform - Mobile Extra Information - We're planning to do the actual reorganization of the modulesets as soon as possible during this development cycle. The idea is that GNOME 3 is released using the new modulesets. The long term plan for the GNOME applications that were removed from the Desktop, Admin and Dev Tools modulesets is to simply highlight the high-quality applications using the GNOME platform through our communication channels (release notes, website, etc). There will be no official apps anymore and no 'Applications' moduleset in the GNOME releases. The goal here is be more open with the app developer community around GNOME and to highlight all the nice things that can be created using our platform. Comments, ideas, and suggestions are welcome. Cheers! The Release Team ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Hi Paolo, 2010/6/2 Paolo Borelli pbore...@katamail.com: On Wed, 2010-06-02 at 00:37 +0100, Lucas Rocha wrote: The long term plan for the GNOME applications that were removed from the Desktop, Admin and Dev Tools modulesets is to simply highlight the high-quality applications using the GNOME platform through our communication channels (release notes, website, etc). There will be no official apps anymore and no 'Applications' moduleset in the GNOME releases. The goal here is be more open with the app developer community around GNOME and to highlight all the nice things that can be created using our platform. Personally I think the idea of giving up on having an Applications moduleset is a very unfortunate decision for multiple reasons: - first and foremost it will drive away fresh forces from gnome: most of new developers get involved in writing code for applications and feeling officially part of gnome is a determining factor in getting more involved in desktop-wide hacking, in the community mailing lists, join the foundation and so on - Cross-application hacking will slowly vanish, slowly ruining the quality and consistency of the gnome desktop. For instance until a few years back we had ui revisions for all gnome application each cycle which ensured consistency and quality... I think we should work on getting this kind of thing back (especially since gnome 3 will bring some changes to the ui!) instead this decision will make each application go its own way - QA effort will be impacted: I used to run a full jhbuild version of gnome all the time and I don't anymore and I think I am not the only one... This is a problem on its own (and something the RT should work on!), but if jhbuild build does not build a full desktop anymore (or if it takes 2 days to build because it pulls in 6 media players) we are once again moving in the wrong direction - A particular note goes to also giving up on the Dev Tools moduleset: new developers ask all the time about which tools should they use to hack on gnome, the dev tools moduleset was starting to become a decent answer to that (though I certainly wish it provided a more complete development environment and more tools were added, eg sysprof). Giving up on creating an official moduleset is a step back since we cannot say Want to hack on gnome? Here are the tools of the trade I am really sorry to say it, but this feels like the gnome chronic inability to make decisions: we are not able to pick RhythmBox or Banshee, we are not able to deal with Zeitgeist being on LaunchPad, etc... so the only decision we are able to make is to cop out on making decisions. I don't see this as a move to avoid decisions. It's more about being inclusive with app developers. Why do we have to choose between high-quality competing apps? If they follow GNOME guidelines, use our platform, are well implemented, have a lively user community, I'd prefer to have both considered as first-class citizens in GNOME. I would only care about not having competing implementations of the same thing in desktop core which is the part where we actually want to have more control. --lucasr ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, 2010-06-02 at 00:37 +0100, Lucas Rocha wrote: Extra Information - We're planning to do the actual reorganization of the modulesets as soon as possible during this development cycle. The idea is that GNOME 3 is released using the new modulesets. The long term plan for the GNOME applications that were removed from the Desktop, Admin and Dev Tools modulesets is to simply highlight the high-quality applications using the GNOME platform through our communication channels (release notes, website, etc). There will be no official apps anymore and no 'Applications' moduleset in the GNOME releases. The goal here is be more open with the app developer community around GNOME and to highlight all the nice things that can be created using our platform. I'll mirror Xavier's problem that Empathy would be just as GNOME as Pidgin by adding that the same problem would happen to Totem. Is a video player that doesn't use GStreamer alright? Is a video player that doesn't follow the GNOME Schedule alright? We might have ended up with gxine in GNOME if it were the case, and I wouldn't have started Totem some 9 years ago. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Il giorno mer, 02/06/2010 alle 08.50 +0200, Xavier Claessens ha scritto: The long term plan for the GNOME applications that were removed from the Desktop, Admin and Dev Tools modulesets is to simply highlight the high-quality applications using the GNOME platform through our communication channels (release notes, website, etc). There will be no official apps anymore and no 'Applications' moduleset in the GNOME releases. The goal here is be more open with the app developer community around GNOME and to highlight all the nice things that can be created using our platform. I understand the difficulties to maintain an Application moduleset, and the need to extend a bit the definition to more modules, but I don't think this is the right solution. With that definition, Pidgin is as GNOME as Empathy then ?!? That means that GNOME applications could live in any VCS, on any server/infrastructure, with any licence, etc ?!? That will be a mess. snip Xavier already exposed my own concerns here, I just want to point two more plausible issues: * translations - as Italian team coordinator I could say that in 2.x cycle we was able to provide good (or even excellent) quality translations for GNOME Desktop due to the planned release schedule AND the inclusion of basic applications in Desktop. This reorganization makes me fear we'll have to spend more time searching when, where and how provide new or updated translation for new applications that will have a relevant role for user experience. See for instance the nautilus-imobiledevice that Bastien blogged just yesterday: it's on a private git repository, you have to generate the POT file by yourself, you have to find how to submit it (and anybody will be able to do it: bazaar[1] is beautiful, but sometimes not great for quality) in the hope developers will not add new strings just 2 hours before release it :| * external deps - the previous Application moduleset worked also to prevent applications to use exotic libraries as external deps. The deal was simple: If you want to be an official GNOME application, then depends approved libs and only suggest other stuff. Now? Do we'll have some rule for applications that we will sponsor on gnome.org? [1] not the VCS :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Il giorno mer, 02/06/2010 alle 12.08 +0200, Paolo Borelli ha scritto: - QA effort will be impacted: I used to run a full jhbuild version of gnome all the time and I don't anymore and I think I am not the only one... This is a problem on its own (and something the RT should work on!), but if jhbuild build does not build a full desktop anymore (or if it takes 2 days to build because it pulls in 6 media players) we are once again moving in the wrong direction Yes, JHBuild is a great resource, we should make it work and ask developers to use as approved reference platform for GNOME Applications. Something like: if you want to develop for GNOME, then install a jhbuild sandbox (stable or development) and make your application build and work inside it. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Qua, 2010-06-02 às 12:06 +0100, Bastien Nocera escreveu: On Wed, 2010-06-02 at 00:37 +0100, Lucas Rocha wrote: Extra Information - We're planning to do the actual reorganization of the modulesets as soon as possible during this development cycle. The idea is that GNOME 3 is released using the new modulesets. The long term plan for the GNOME applications that were removed from the Desktop, Admin and Dev Tools modulesets is to simply highlight the high-quality applications using the GNOME platform through our communication channels (release notes, website, etc). There will be no official apps anymore and no 'Applications' moduleset in the GNOME releases. The goal here is be more open with the app developer community around GNOME and to highlight all the nice things that can be created using our platform. I'll mirror Xavier's problem that Empathy would be just as GNOME as Pidgin by adding that the same problem would happen to Totem. Is a video player that doesn't use GStreamer alright? Is a video player that doesn't follow the GNOME Schedule alright? We might have ended up with gxine in GNOME if it were the case, and I wouldn't have started Totem some 9 years ago. I agree... also that means that most of the applications out there that will be blessed by GNOME won't work on GNOME 3.0. See pidgin, gxine, gnomebaker etc... that doesn't follow GNOMEGoals and would make them broken for GNOME Releases. Also not following GNOME Schedule means that will have many problems on QA, Documentation and Translations. Cheers Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Am Mittwoch, den 02.06.2010, 13:11 +0200 schrieb Luca Ferretti: if you want to develop for GNOME, then install a jhbuild sandbox (stable or development) and make your application build and work inside it. Depends on how you define build and work, but pretty exactly half of the current module maintainers already fail with fulfilling such a requirement. See stats at http://build.gnome.org/ . ;-) andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Hi! Depends on how you define build and work, but pretty exactly half of the current module maintainers already fail with fulfilling such a requirement. See stats at http://build.gnome.org/ . ;-) I guess that is because not so many people look at this stats and because the build environment is limited to some extend (some m4 stuff failing, etc.). I wouldn't trust in those stats too much though we should definitely try to fix this. Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, 2010-06-02 at 13:19 +0200, Andre Klapper wrote: Am Mittwoch, den 02.06.2010, 13:11 +0200 schrieb Luca Ferretti: if you want to develop for GNOME, then install a jhbuild sandbox (stable or development) and make your application build and work inside it. Depends on how you define build and work, but pretty exactly half of the current module maintainers already fail with fulfilling such a requirement. See stats at http://build.gnome.org/ . ;-) I would agree if the 2 failures I saw (totem and totem-pl-parser) weren't related to working from dirty git trees that fail to merge. And the gnome-bluetooth bug is due to your dbus-glib having missing introspection support. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, 2010-06-02 at 13:19 +0200, Andre Klapper wrote: Am Mittwoch, den 02.06.2010, 13:11 +0200 schrieb Luca Ferretti: if you want to develop for GNOME, then install a jhbuild sandbox (stable or development) and make your application build and work inside it. Depends on how you define build and work, but pretty exactly half of the current module maintainers already fail with fulfilling such a requirement. See stats at http://build.gnome.org/ . ;-) just had a quick look at gnome-settings-daemon, and it's failing because of missing X* data types, so I guess it's missing some dependencies? Maybe that's the same for lots of other modules? In fact, when running jhbuild from scratch, I always end up having to install several xorg-*-dev packages. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Am Mittwoch, den 02.06.2010, 11:59 +0100 schrieb Lucas Rocha: I am really sorry to say it, but this feels like the gnome chronic inability to make decisions: we are not able to pick RhythmBox or Banshee, we are not able to deal with Zeitgeist being on LaunchPad, etc... so the only decision we are able to make is to cop out on making decisions. I don't see this as a move to avoid decisions. It's more about being inclusive with app developers. Why do we have to choose between high-quality competing apps? If they follow GNOME guidelines, use our platform, are well implemented, have a lively user community, I'd prefer to have both considered as first-class citizens in GNOME. It depends on the GNOME guidelines to follow. If these are the ones needed to be fulfilled for entering the Desktop module set (under the current/old policy), e.g. six months release cycle, hosted on and using GNOME infrastructure etc, then I'd guess everything would be fine. The only change then would be that we'd bless multiple similar applications. The decision should not be Rhythmbox *or* Banshee, but Is Rhythmbox good enough? and Is Banshee good enough?. Hendrik ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, 2010-06-02 at 13:38 +0200, Rodrigo Moya wrote: On Wed, 2010-06-02 at 13:19 +0200, Andre Klapper wrote: Am Mittwoch, den 02.06.2010, 13:11 +0200 schrieb Luca Ferretti: if you want to develop for GNOME, then install a jhbuild sandbox (stable or development) and make your application build and work inside it. Depends on how you define build and work, but pretty exactly half of the current module maintainers already fail with fulfilling such a requirement. See stats at http://build.gnome.org/ . ;-) just had a quick look at gnome-settings-daemon, and it's failing because of missing X* data types, so I guess it's missing some dependencies? Those should be checked for in the configure script. Maybe that's the same for lots of other modules? In fact, when running jhbuild from scratch, I always end up having to install several xorg-*-dev packages. That's when it should fail in configure, not building. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
...total nightmare... ...crush all these efforts... I understand that change is uncomfortable and incites fear, but can we please lay off the melodramatic voice here ? There's three basic facts that lead us to this proposal: 1. We have an ever-growing set of modules and a constantly expanding set of external dependencies. It is basically impossible to get a complete jhbuild tree built at any given time. 2. The much touted homogeneity and consistent quality of GNOME is (imho) largely a thing of the past. There have been no organized UI reviews of new modules in a long time, the HIG has not been updated to match the UIs we see in current applications. 3. The release team is not growing (in fact, several members have already announced their plans to step down after 3.0) For things to be different and better in GNOME3, we need a shared vision that applications can strive to follow - where is the updated HIG for GNOME3 ? Where is the roadmap that leads us beyond the next 6 month release cycle ? And we need people to step up and work on this shared vision. Where are the new release team members ? Where are the people who are willing to update the HIG and do UI reviews to make it take effect ? Sorry if this sounded negative... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Hi Lucas, On Wed, 2010-06-02 at 11:59 +0100, Lucas Rocha wrote: I don't see this as a move to avoid decisions. It's more about being inclusive with app developers. Why do we have to choose between high-quality competing apps? If they follow GNOME guidelines, use our platform, are well implemented, have a lively user community, I'd prefer to have both considered as first-class citizens in GNOME. But this way you are not being equally inclusive, you are being equally exclusive. Applications writers wants their app delivered to the users, on linux this means shipped by distributions: a well defined gnome desktop is a way for distributors to delegate to gnome a lot of the decision-making in exchange for high quality standards. If being part of gnome is loosened into a set of guidelines to comply with, gnome will just become an external dependency for the application itself and all the decision making will happen downstream, which inevitably means that: - applications developers will move downstream near distributions to make sure their app is shipped as default - design discussion will happen downstream to make sure the apps fits well in the target distribution - QA will move downstream to make sure app works well in release X of distro Y (opposed to works well in gnome 2.30) - cross-app integration will move downstream (e.g. apps will assume that a pdf is opened in the pdf reader shipped by ditro X, not by the gnome pdf reader) - documentation will move downstream since it is where they can concentrate on a well defined experience to be documented. - technology choices will move downstream (eg use the lib used by distribution X for notifications etc) But most important of all, new contributors will simply join downstream and get involved there, since downstream provides all the required facilities (code hosting, discussion forums, conferences, etc) and very few of them will make the leap of contributing to the core gnome platform since it will just be seen as a disconnected external entity providing some basic functionality they take for granted. Ciao Paolo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
From: Bastien Nocera had...@hadess.net On Wed, 2010-06-02 at 13:38 +0200, Rodrigo Moya wrote: On Wed, 2010-06-02 at 13:19 +0200, Andre Klapper wrote: Am Mittwoch, den 02.06.2010, 13:11 +0200 schrieb Luca Ferretti: if you want to develop for GNOME, then install a jhbuild sandbox (stable or development) and make your application build and work inside it. Depends on how you define build and work, but pretty exactly half of the current module maintainers already fail with fulfilling such a requirement. See stats at http://build.gnome.org/ . ;-) just had a quick look at gnome-settings-daemon, and it's failing because of missing X* data types, so I guess it's missing some dependencies? Yes, probably there are some dependencies missing in the slave machine. Those should be checked for in the configure script. But definitively, this would mean that it would fail building the module, if we think the concept build as checkout + configure + compile + install. Maybe that's the same for lots of other modules? Yes probably. Probably offtopic in this thread, but this reminds me that it would be good to make a general review on the RHEL5, in order, to at least, have installed all the required dependencies, as it is being done randomly at this moment [1] BR [1] http://mail.gnome.org/archives/build-brigade-list/2010-March/msg2.html === API (apinhe...@igalia.com) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Hi, 2010/6/2 Josselin Mouette j...@debian.org: Le mercredi 02 juin 2010 à 11:59 +0100, Lucas Rocha a écrit : I don't see this as a move to avoid decisions. It's more about being inclusive with app developers. Why do we have to choose between high-quality competing apps? If they follow GNOME guidelines, use our platform, are well implemented, have a lively user community, I'd prefer to have both considered as first-class citizens in GNOME. http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html I think you missed the point. We're not distros. We provide a platform and components to build distros and other products. So, yes, distros should probably just pick the software that best fit their target audience and stick with them. So, the argument in the linked message doesn't apply to us in the exact same way than distros. --lucasr ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Am Mittwoch, den 02.06.2010, 13:54 +0200 schrieb Josselin Mouette: http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html Aha. So? Distributions have been and still will be able to make decisions. andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Hi! ...total nightmare... ...crush all these efforts... I understand that change is uncomfortable and incites fear, but can we please lay off the melodramatic voice here ? Good idea, sorry if my previous mail probably failed a bit here. 1. We have an ever-growing set of modules and a constantly expanding set of external dependencies. It is basically impossible to get a complete jhbuild tree built at any given time. I think the point is rather about the Application module (or for the lack of it). Many people (including me) would like to see an official set of blessed applications that are known to be accessible, translated, stable and that follow the schedule. And this should be formal rather than only a promotion set. 2. The much touted homogeneity and consistent quality of GNOME is (imho) largely a thing of the past. There have been no organized UI reviews of new modules in a long time, the HIG has not been updated to match the UIs we see in current applications. Something we should fix? I think so! 3. The release team is not growing (in fact, several members have already announced their plans to step down after 3.0) For things to be different and better in GNOME3, we need a shared vision that applications can strive to follow - where is the updated HIG for GNOME3 ? Where is the roadmap that leads us beyond the next 6 month release cycle ? And we need people to step up and work on this shared vision. Where are the new release team members ? Where are the people who are willing to update the HIG and do UI reviews to make it take effect ? Well, you cannot point on the community here: The release team is not directly elected, but should be representative of the GNOME community. Membership is normally by invite and recommendation when one person leaves. I am sure there are people who want to help out! But I fully agree that we should put effort into creating the vision. This discussion and the discussion on the foundation-list are a good starting point though. Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On 1 June 2010 19:37, Lucas Rocha luc...@gnome.org wrote: 3. We strongly believe that we should encourage a strong ecosystem of apps around GNOME, and integrating all applications in the GNOME Desktop moduleset is not the best way to achieve this. As the maintainer of Déjà Dup, I approve of this move. I feel Déjà Dup is a bit of a poster child for this change. 1) Déjà Dup already follows the GNOME schedule, watches GnomeGoals, follows HIG, and uses GNOME technology. 2) Déjà Dup is already shipped in multiple distros. Inclusion in GNOME would just offer more marketing/developers (of which I'm primarily interested in the latter), not necessarily Déjà Dup's 'chance to hit it big'. 3) Déjà Dup already has an infrastructure that works for me. I'd be very sad to move away from Launchpad, but was willing to do if it meant access to the extra exposure. But am glad to hear that I won't need to. I don't think using, say, GNOME Bugzilla would improve my chances of attracting developers. 4) Not being under the watchful eye of release managers means I can be slightly more adventurous (don't need to have dependencies approved). One thing I had hoped to gain access to via GNOME is the documentation teams and translation teams. Launchpad provides very good translation support, so I'm not hurting there, but my understanding is that the GNOME translation teams are more comprehensive/committed. It would be nice if the new Applications scheme had some facility for improving cooperation between those teams and externally-hosted applications. Maybe for willing applications in Launchpad, that means: 1) Having an approved GNOME coding team (~gnome-team?) that the maintainer sets to own the branch. This way, documenters and GNOME-approved coders can directly commit. 2) Having the maintainer set the approved translation team to '~gnome-translation-project' and having some documentation for translators that this particular app lives in launchpad. With Launchpad, they wouldn't need direct access to trunk, but it wouldn't hurt if they chose to edit directly instead of the web interface. 3) For documentation, a similar situation. Have some documentation for them that says, 'for this app, edit docs in this trunk'. Then they could directly commit. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Il giorno mer, 02/06/2010 alle 07.52 -0400, Matthias Clasen ha scritto: There have been no organized UI reviews of new modules in a long time, the HIG has not been updated to match the UIs we see in current applications. I'm not against evolution of HIG in time, but shouldn't be applications to update (fix) themself to match HIG?!?! However, what's the current status of HIG update? What will be the relevant changes? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Le mercredi 02 juin 2010 à 13:04 +0100, Lucas Rocha a écrit : http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html I think you missed the point. We're not distros. We provide a platform and components to build distros and other products. So, yes, distros should probably just pick the software that best fit their target audience and stick with them. So, the argument in the linked message doesn't apply to us in the exact same way than distros. Maybe not in the exact same way, but I fail to see why it wouldn’t apply. Let’s take a simple example. People write two different burning applications, SuperBurn and MegaBurn. GNOME doesn’t want to pick one of them in the official module set and just features them both. The sound-juicer developers prefer SuperBurn and tightly integrate s-j with it. OTOH the rhythmbox developers love MegaBurn and write advanced plugins for it, while integrating SuperBurn is limited for technical reasons. Facing such a situation, we distributors have no good solution. We can choose to ship one or the other solution, but it will be less satisfactory and will require more resources than having one of them chosen by GNOME. In this example, we were able to switch from n-c-b to brasero in a single shot with one major GNOME release; we would never have been able to do so if the GNOME release team hadn’t made a decision. The brasero support in applications would never have been so good if the switch had been made optional. The fact that we can (and will) make decisions will not magically bring the same amount of resources into supporting them without upstream backing us. Cheers, -- .''`. Josselin Mouette : :' : `. `' “A handshake with whitnesses is the same `- as a signed contact.” -- Jörg Schilling ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Sorry for replying out of thread - i've been following the discussion from web. As one of the apps (project hamster) that prolly will fall out of the category, wanted to share my sentiment. Project hamster being part of GNOME means many things to me and there are many benefits: * promotion - distros are recommended to include your application in default set * i18n - there is no way hamster would have gotten the localizers in such a rapid pace as right after being included in gnome * quality - i was not the sole person looking to match gnome's quality expectations any more. * release cycle - we sure can just follow the gnome schedule instead of being required to do it - but it's like following aerobics on TV opposed to being in the gym. There is difference and there is the silliness that you might be just mimicking the actions without anybody really caring about it. * credibility as a dev - i believe that it gives you certain credibility that you might know what you are doing if your patches are constantly accepted in an application that is official part of gnome My question is - which parts will we be losing by this move? Can't be none - because then nothing's really changing, now, is it? Toms On Wed, Jun 2, 2010 at 10:08 AM, Patryk Zawadzki patrys pld-linux org wrote: The long term plan for the GNOME applications that were removed from the Desktop, Admin and Dev Tools modulesets is to simply highlight the high-quality applications using the GNOME platform through our communication channels (release notes, website, etc). There will be no official apps anymore and no 'Applications' moduleset in the GNOME releases. The goal here is be more open with the app developer community around GNOME and to highlight all the nice things that can be created using our platform. And this might do the exact opposite of what we all want it to do. Instead of sending a you are now all equal message it might communicate that you are now equally not worthy. Or just you are now on the same level even if the level of integration and sheer polish is nowhere to be compared. It will also kill the magic moment I experienced twice - once when I helped Daniel with Cheese and a second time when hacking on Hasmter with Toms. The moment that comes after weeks of mad hacking when you decide your work is finally good enough to become part of GNOME. Forgot to mention: not having a single release schedule will also make it very hard for app authors to propose, track and depend on features of the underlying platform or - even worse - features introduced in other apps. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, 2010-06-02 at 08:54 -0400, Michael Terry wrote: 3) Déjà Dup already has an infrastructure that works for me. I'd be very sad to move away from Launchpad, but was willing to do if it meant access to the extra exposure. But am glad to hear that I won't need to. I don't think using, say, GNOME Bugzilla would improve my chances of attracting developers. As somebody who works on a big number of applications, I'm more likely to do drive by bug fixing if your application lives in the GNOME repos, and uses GNOME Bugzilla. And I'd like to dispel that myth that only applications in the GNOME Desktop release can use the gnome.org infrastructure. I've seen a number of applications be developed on third-party hosting sites because they didn't know any better. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
2. The much touted homogeneity and consistent quality of GNOME is (imho) largely a thing of the past. There have been no organized UI reviews of new modules in a long time, the HIG has not been updated to match the UIs we see in current applications. Something we should fix? I think so! Agreed. Quite a bit of work was done on reviewing Deja Dup's UI after it applied for module inclusion [1]. That review wasn't 'organised' as such, and it wasn't particularly integrated into the module inclusion process (my bad), but it did happen. We can work to develop that side of things if that's what people want to do. As for the HIG [2], I'm confident that we will have a substantial portion of it finished for 3.0. Allan [1] http://live.gnome.org/DejaDup/Design/Review-2010-05 [2] http://live.gnome.org/UsabilityProject/HIG/ -- GoogleTalk: allanpday AT gmail DOT com IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, 2010-06-02 at 08:54 -0400, Michael Terry wrote: Maybe for willing applications in Launchpad, that means: 1) Having an approved GNOME coding team (~gnome-team?) that the maintainer sets to own the branch. This way, documenters and GNOME-approved coders can directly commit. 2) Having the maintainer set the approved translation team to '~gnome-translation-project' and having some documentation for translators that this particular app lives in launchpad. With Launchpad, they wouldn't need direct access to trunk, but it wouldn't hurt if they chose to edit directly instead of the web interface. 3) For documentation, a similar situation. Have some documentation for them that says, 'for this app, edit docs in this trunk'. Then they could directly commit. If we're to allow external hosting for blessed applications (to whatever extent we're blessing applications), these rules would go a long way towards helping bridge the gap. But the gap will still be there. It's just more stuff to think about for contributors, and for non-git hosting services, it's another VCS to learn. There's a lot of stuff I have to teach new documentation contributors, and adding another VCS to the mix doesn't help. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, 2010-06-02 at 07:52 -0400, Matthias Clasen wrote: For things to be different and better in GNOME3, we need a shared vision that applications can strive to follow - where is the updated HIG for GNOME3 ? There is a HIG 3.0 Workshop scheduled for the GUADEC pre-conference: http://live.gnome.org/GUADEC/2010/BOFs I've also my documentation workshop to the usability team to work further on the HIG. I can help with writing, editing, markup, organization, etc. But others will have to decide what goes in and what doesn't. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On 2 Jun 2010, at 12:52, Matthias Clasen wrote: For things to be different and better in GNOME3, we need a shared vision that applications can strive to follow - where is the updated HIG for GNOME3 ? It's under way. http://library.gnome.org/UsabilityProject/HIG -- CALUM BENSON, Interaction Designer Oracle Corporation, Ireland mailto:calum.ben...@oracle.com Solaris Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Oracle Corp. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, Jun 2, 2010 at 11:00 AM, Shaun McCance sha...@gnome.org wrote: If we're to allow external hosting for blessed applications (to whatever extent we're blessing applications), these rules would go a long way towards helping bridge the gap. But the gap will still be there. It's just more stuff to think about for contributors, and for non-git hosting services, it's another VCS to learn. There's a lot of stuff I have to teach new documentation contributors, and adding another VCS to the mix doesn't help. I think there's a misunderstanding that applications would be blessed at all. The way this change was proposed in the GNOME Boston Summit 2009 and the way the announcement reads, applications are merely awesome to the point of having a sufficient level of community mind-share, like in other free software communities, or they are hosted on our infrastructure (which is really easy to have happen now) and easier to contribute to because of that. Remember, any reasonably GNOME-related is welcome to be hosted on our infrastructure. From the Marketing Team's perspective, we will mention and showcase apps which have that high level of community mind-share. That basically means everything that's currently in the Desktop suite plus a whole lot more. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Tue, Jun 1, 2010 at 7:37 PM, Lucas Rocha luc...@gnome.org wrote: Extra Information - We're planning to do the actual reorganization of the modulesets as soon as possible during this development cycle. The idea is that GNOME 3 is released using the new modulesets. The long term plan for the GNOME applications that were removed from the Desktop, Admin and Dev Tools modulesets is to simply highlight the high-quality applications using the GNOME platform through our communication channels (release notes, website, etc). There will be no official apps anymore and no 'Applications' moduleset in the GNOME releases. The goal here is be more open with the app developer community around GNOME and to highlight all the nice things that can be created using our platform. I want to say that I am really happy about this proposal! As co-maintainer of GNOME Games, I have had to constantly turn down people whom want their game included in the distribution only to obtain the recognition that would come with that inclusion. Some of the games that have been proposed have been of a really high quality but, for example, didn't fit the language knowledge of the current maintainers. By downgrading GNOME Games to the same level as all those others that have been proposed, distributions will be encouraged to find other alternative games from the wider GNOME community. That would be a good thing! Others have expressed worry about translations and documentation. I'm not worried about that GNOME Games has the history and mind-share to ensure that people working on our infrastructure make a habit out of working on the GNOME Games, regardless of its status. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, Jun 2, 2010 at 6:42 AM, Luca Ferretti lferr...@gnome.org wrote: Il giorno mer, 02/06/2010 alle 18.14 +0800, Paul Cutler ha scritto: To market these apps effectively, they will need to adhere to GNOME guidelines and processes. They'll need to be free software, they'll need to be localized, they'll need documentation, they'll need to be accessible. Then, and only then, should we be marketing to them on places like GNOME.org. Who will be in charge to choose those applications? I suppose we'll still need to propose them on some mailing list and ask comments from community and groups. I didn't see anyone else respond to this so I wanted to chime in as a member of the Marketing Committee. We are all active members of the GNOME Community and we know which apps are popular and are included by default in different distributions. We all use different distributions which choose different defaults; each distribution was well-represented by members of the Committee at the Zaragoza hackfest a few weeks ago. In short, the Marketing Committee is well-positioned to understand which apps to highlight in release notes, videos and brocures, for example. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, 2010-06-02 at 13:40 -0400, Jason D. Clinton wrote: On Wed, Jun 2, 2010 at 11:00 AM, Shaun McCance sha...@gnome.org wrote: If we're to allow external hosting for blessed applications (to whatever extent we're blessing applications), these rules would go a long way towards helping bridge the gap. But the gap will still be there. It's just more stuff to think about for contributors, and for non-git hosting services, it's another VCS to learn. There's a lot of stuff I have to teach new documentation contributors, and adding another VCS to the mix doesn't help. I think there's a misunderstanding that applications would be blessed at all. The way this change was proposed in the GNOME Boston Summit 2009 and the way the announcement reads, applications are merely awesome to the point of having a sufficient level of community mind-share, like in other free software communities, or they are hosted on our infrastructure (which is really easy to have happen now) and easier to contribute to because of that. Remember, any reasonably GNOME-related is welcome to be hosted on our infrastructure. From the Marketing Team's perspective, we will mention and showcase apps which have that high level of community mind-share. That basically means everything that's currently in the Desktop suite plus a whole lot more. This scares me a lot, for a number of reasons: 1) All I've seen are kind of vague ideas of promoting applications through our communications channels. Our communications channels aren't that awesome. Our website is disorganized and often out of date. We don't have an application showcase. This is all fixable, of course. But before we just throw away our finely-tuned release sets in the hope for something better, I'd like to see very concrete and attainable plans for that something. 2) Translators no longer have any idea what's a priority. How do we determine what makes a language fully supported? 3) Documentation writers no longer have any idea what's a priority. Sure, many of us will just work on popular applications (or those we personally like) regardless of inclusion. But it's really nice to be able to point people to a definitive list of things that we consider a priority. 4) Inter-application integration just gets way harder. Yelp can now use nautilus-sendto. GTG has can talk to Hamster. Lots of people are talking about integrating with Cheese. It is really useful to be able to look at a list of applications to figure out ways you can integrate better. Without a list, we have to just kind of watch the ethereal space of what was hot on our site for a few days. 5) Without any notion of inclusion in a blessed list, release schedules diverge, which compounds the above problems. 6) Who decides what gets promoted? It sounds like the marketing team alone, if they're the ones doing the promotion. That's not necessarily bad, and I want the marketing team to take a more active role. But we'll lose the fantastic whole-community input we get with our module discussions. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, 2010-06-02 at 13:07 -0500, Shaun McCance wrote: 6) Who decides what gets promoted? It sounds like the marketing team alone, if they're the ones doing the promotion. That's not necessarily bad, and I want the marketing team to take a more active role. But we'll lose the fantastic whole-community input we get with our module discussions. I just wanted to clarify this, after reading Jason's response to Luca. I'm not worried about who makes the decisions. Our teams are open and made up of our community. I'm concerned with where the discussions happen. We can't all be on every mailing list, and it's nice to get the whole community involved when we talk about what we want GNOME to feature. And right now, d-d-l has the widest cross section of our community. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, Jun 2, 2010 at 7:54 PM, Jason D. Clinton m...@jasonclinton.com wrote: We are all active members of the GNOME Community and we know which apps are popular and are included by default in different distributions. We all use different distributions which choose different defaults; each distribution was well-represented by members of the Committee at the Zaragoza hackfest a few weeks ago. In short, the Marketing Committee is well-positioned to understand which apps to highlight in release notes, videos and brocures, for example. It should be the other way around. Applications that are already popular don't need showcasing and embracing. It's those unknown little gems that need the marketing polish to really shine. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, Jun 2, 2010 at 12:26 PM, Patryk Zawadzki pat...@pld-linux.org wrote: It should be the other way around. Applications that are already popular don't need showcasing and embracing. It's those unknown little gems that need the marketing polish to really shine. Well known in our community and well known in general are two very different things. I have yet to meet anyone without a computer related job or interest in free software that knows what GNOME is. If we want them to use GNOME, it's even more important that they know our applications and those brands are even less recognized. (I did run into a GIMP fan the other day. Someone not in the free software world. He converted his whole work place from Photoshop to GIMP.) Stormy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, 2010-06-02 at 07:52 -0400, Matthias Clasen wrote: ...total nightmare... ...crush all these efforts... I understand that change is uncomfortable and incites fear, but can we please lay off the melodramatic voice here ? There's three basic facts that lead us to this proposal: 1. We have an ever-growing set of modules and a constantly expanding set of external dependencies. Because the release team has been saying Yes too easily. It is basically impossible to get a complete jhbuild tree built at any given time. 2. The much touted homogeneity and consistent quality of GNOME is (imho) largely a thing of the past. Because the release team has been saying Yes too easily. There have been no organized UI reviews of new modules in a long time, the HIG has not been updated to match the UIs we see in current applications. [snip] -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, Jun 2, 2010 at 3:14 PM, Murray Cumming murr...@murrayc.com wrote: On Wed, 2010-06-02 at 07:52 -0400, Matthias Clasen wrote: ...total nightmare... ...crush all these efforts... I understand that change is uncomfortable and incites fear, but can we please lay off the melodramatic voice here ? There's three basic facts that lead us to this proposal: 1. We have an ever-growing set of modules and a constantly expanding set of external dependencies. Sorry to jump in the middle here, I did read the 60 some emails. Generally I share the feeling of dismay about losing some important order that we have in GNOME. Also I feel like this coming year might really be the year for gnome devtools... The success of the potential features I have in mind for Glade/GTK+ (and hopefully Anjuta) are going to depend vitally on how tightly we can integrate our developer tools together as a unified chain. Regardless of my bias in this matter as one who advocated the devtools suite in the past, I can definitely feel Matthias's pain expressed here that we are just running low on resources to manage it and as such maybe the overly large desktop suite is becoming unmanageable. So, if there are too many apps in the desktop suite (or in other suites) could we just try to clean it up somehow ? The process could be something like: - Release team decides what modules to thow away for GNOME 3.0 - Gruesome exciting technical battles occur on d-d-l as the over-all 3.0 module inclusion discussion heats up - Release team and the community would have to help to defend the relevance of older modules inclusion in GNOME 3.0 (for modules who's maintainers can not be contacted). - Accepted modules would at least have to build against the new stack as a minimum bar for passing (i.e. fully GSEALed GTK+ and only apis available in the new platform). I'm sure that 3.0 is a great time to throw away alot of stuff that may have become irrelevant over the years. This route would also hopefully offload a significant part of the work to the community (each maintainer would have to re-defend their module's significance in the new GNOME)... allowing the release-team to focus on other things while the community dukes it out... This could even be a process with an undefined timeline, 3.0 could just start with an empty applications suite and we could go on in the usual way [re]adding new applications every 6 months. Thoughts ? Cheers, -Tristan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Hey Lucas, Overall this sounds good to me. Definitely a step in the right direction. ... In summary, this means that the GNOME releases would be composed by the following modulesets: - Desktop - Platform - Extended Platform - Mobile A few questions about this list. Is Platform a platform for creating an OS core or a platform for creating applications? There is a difference. Today, our story there is muddy. We don't really have a strong application development platform. Certainly, for example, nothing like: http://developer.palm.com/index.php?option=com_contentview=articleid=1654 If Platform really means OS Platform then I'm not sure it makes sense to identify this separately from the product release (that which we call Desktop now). Why is Mobile separate? I suppose this really means Mobile OS Platform since we don't yet have a GNOME user experience for mobile devices. However, since GNOME 3 is already targeting netbooks and tablets we will soon. I would say that we shouldn't dilute the GNOME brand and resources on a Mobile module set until we have a GNOME user experience for handhelds. GNOME 3 is not a grab bag. It is a set of experiences around an OS. This OS is defined by the user experience of the core (or shell) and the vibrancy of the marketplace of add-ons (applications). The vibrancy of the marketplace is at least partially related to the simplicity, coherency, and suitability of the application development platform. To me, GNOME offers three things: 1. Core OS user experience 2. Application developer experience 3. Application ecosystem With GNOME 3, so far, we have been focused on addressing 1. And this proposal partly reflects that. But I think we'll need to eventually shift our focus to the other two. We haven't really tried to design 2 much yet - not from an experience design perspective anyway. So, what is part of 1 and what is part of 3? One way would be to start by ask the following questions: * Does the overall design of the system call for it? * Is it compatible with the core system design? * Does it integrate tightly with the core system? * Does it meet all of the minimum requirements for the core system? * Are you willing for it to have a generic identify or lack a distinct identity and be only part of the system core? (See http://blogs.gnome.org/mccann/2009/08/08/whatchamacallit/) * etc. If the answer to any of those is no then it should not be a part of the core user experience I think. Here are three examples. (to be more concrete but please don't get sidetracked by them) Example 1: Empathy The overall system design calls for including chat and contacts functionality. It meets most or all of the requirements. It is a great app made by folks committed to the success of GNOME. However, with such a rubric we'd want to rename the tool to Chat or similar and ensure that it continues to be more integrated with the core. The good news is that it sounds like this is ongoing or under consideration already. Example 2: Caribou The core system design calls for an on screen keyboard: http://live.gnome.org/GnomeShell/Design/Whiteboards/ScreenKeyboard . However, we haven't yet determined the details of the design or how it would integrate or cooperate with the Shell or a11y or i18n input methods etc. (help appreciated there btw) So, unfortunately until we do that it shouldn't be in the core. Not due to any failings of the tool authors at all. But the default should be out, not in. And there are many other examples of quality applications that (it seems) would very much prefer to remain separate and have a separate brand identity: gedit, inkscape, shotwell, etc. So, they should not be part of the core either. That said, we aren't doing anyone a service by just turning our backs on great software. On the contrary, we need to foster and encourage it (this is number 3 above). Communities and ideas like this need a place to make them seem real. Even if that place isn't the only one and even if it is only symbolic. I propose that we create a GNOME Marketplace for applications, games, and utilities that aren't part of the GNOME core. If we do it well then this will actually provide a lot more value to the application authors than we ever could by simply accepting it into a list of desktop modules. Think of it as a living module set. Once we decouple application development from the core OS development we'll quickly find that our application developer experience is less than ideal (number 2 above). So, ideally, it would be better if we work on them in concert. So, what does this mean with respect to your proposal? Maybe: * Rename Desktop to Desktop Core (or similar) * Drop Mobile for now until we start to design a Mobile user experience * Drop Platform for now until we start to design an Application Platform * Create a GNOME Marketplace website and service with client support built into the Desktop Core Things not directly related
Re: Modulesets Reorganization
On 2 June 2010 01:37, Lucas Rocha luc...@gnome.org 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 ___
Re: Modulesets Reorganization
Hi! This discussion is really becoming interesting and constructive. The process could be something like: - Release team decides what modules to thow away for GNOME 3.0 - Gruesome exciting technical battles occur on d-d-l as the over-all 3.0 module inclusion discussion heats up - Release team and the community would have to help to defend the relevance of older modules inclusion in GNOME 3.0 (for modules who's maintainers can not be contacted). - Accepted modules would at least have to build against the new stack as a minimum bar for passing (i.e. fully GSEALed GTK+ and only apis available in the new platform). I'm sure that 3.0 is a great time to throw away alot of stuff that may have become irrelevant over the years. This route would also hopefully offload a significant part of the work to the community (each maintainer would have to re-defend their module's significance in the new GNOME)... allowing the release-team to focus on other things while the community dukes it out... This could even be a process with an undefined timeline, 3.0 could just start with an empty applications suite and we could go on in the usual way [re]adding new applications every 6 months. Thoughts ? I really support Tristan's idea of a restarted review process. This is time consuming but it is rather easy to do on the organsation and infrastructure level. It may or may not be more strict but it would also help to ensure we have some broader vision of application integration in GNOME 3.0. Mikkel's idea with the incubator has charm, too, but I think that should be rather a long time goal for a more formal review process past 3.0! Still, I agree with Bastian that it is far easier to contribute to modules that are centrally hosted than to manage multiple accounts and multiple version control systems. I have the feeling that not everybody is really aware of that especially for people that don't code and are rather unfamiliar with version control and its tools. Regards, Johannes signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, 2010-06-02 at 07:52 -0400, Matthias Clasen wrote: 3. The release team is not growing (in fact, several members have already announced their plans to step down after 3.0) Do we have a process for replacing those outgoing members? Maintainers and coordinators of all teams and projects come and go. It's the way our crazy open world works. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, Jun 2, 2010 at 8:32 PM, Stormy Peters sto...@gnome.org wrote: On Wed, Jun 2, 2010 at 12:26 PM, Patryk Zawadzki pat...@pld-linux.org wrote: It should be the other way around. Applications that are already popular don't need showcasing and embracing. It's those unknown little gems that need the marketing polish to really shine. Well known in our community and well known in general are two very different things. I have yet to meet anyone without a computer related job or interest in free software that knows what GNOME is. If we want them to use GNOME, it's even more important that they know our applications and those brands are even less recognized. (I did run into a GIMP fan the other day. Someone not in the free software world. He converted his whole work place from Photoshop to GIMP.) Decoupling the apps from the desktop could very well end in some of them pursuing their own communities. On the other hand GNOME brand will become even less relevant to an end user — to average Jane in the street GNOME Desktop would constitute nothing more than a wallpaper as only developers know the complexity of the underlying machinery. I hope we won't end up with just a clone of http://gnomefiles.org/ (which I assume could use some help from the Foundation and could then serve as GNOME's official showcase). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Modulesets Reorganization
Hi all, The release team would like to propose some important changes in the way we organize our modulesets. GNOME releases are currently organized into the following modulesets: Desktop, Platform, Bindings, Mobile, Admin, and Dev Tools. This model has served us well and has actually evolved through time - we didn't have the Admin and Dev Tools modulesets initially. However, we feel that this organization is reaching its limits, and we have explored several potential changes. Current issues -- A set of issues makes it clear the need for an evolution here: 1. The arbitrary separation between Platform and Bindings can lead people to think that the bindings are second-class citizens while this is certainly not the case. 2. The Desktop moduleset has expanded so much that it's now unclear which type of application should go in and which shouldn't; it's also forcing us to choose one application over another, or to avoid any decision - like in the famous Rhythmbox vs Banshee case. 3. We strongly believe that we should encourage a strong ecosystem of apps around GNOME, and integrating all applications in the GNOME Desktop moduleset is not the best way to achieve this. 4. Some libraries should be used by developers even if the API/ABI guarantees are not as strong as our GNOME 2 Platform (e.g. GStreamer, e-d-s, and others). Such libraries should be labeled as such, obviously. Proposed (re)organization - With that said, the release team would like to propose the following reorganization of the modulesets: 1. The Desktop moduleset will only contain the components needed to get a desktop session running and provide core functionalities (e.g. gdm, gnome-session, gnome-settings-daemon, nautilus, etc). All applications providing extra relevant features to the desktop (e.g. gedit, Totem, Tomboy, etc) will be moved out from the Desktop moduleset. See the Extra Information section for more details. 2. Bindings will be merged into the Platform moduleset and become first-class citizens on the development Platform. The goal is to make the bindings more prominent from a communication perspective. 3. Create a moduleset to hold our highly recommended libraries such GStreamer, e-d-s, and others. This moduleset will be called Extended Platform. 4. Admin and Dev Tools will be dissolved and will be promoted like any other GNOME application. See the Extra Information section for more details. In summary, this means that the GNOME releases would be composed by the following modulesets: - Desktop - Platform - Extended Platform - Mobile Extra Information - We're planning to do the actual reorganization of the modulesets as soon as possible during this development cycle. The idea is that GNOME 3 is released using the new modulesets. The long term plan for the GNOME applications that were removed from the Desktop, Admin and Dev Tools modulesets is to simply highlight the high-quality applications using the GNOME platform through our communication channels (release notes, website, etc). There will be no official apps anymore and no 'Applications' moduleset in the GNOME releases. The goal here is be more open with the app developer community around GNOME and to highlight all the nice things that can be created using our platform. Comments, ideas, and suggestions are welcome. Cheers! The Release Team ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, 2010-06-02 at 00:37 +0100, Lucas Rocha wrote: Hi all, The release team would like to propose some important changes in the way we organize our modulesets. GNOME releases are currently organized into the following modulesets: Desktop, Platform, Bindings, Mobile, Admin, and Dev Tools. This model has served us well and has actually evolved through time - we didn't have the Admin and Dev Tools modulesets initially. However, we feel that this organization is reaching its limits, and we have explored several potential changes. 1) Do you have a list of what the release team would like to see in the actual Desktop release? There are obvious ins and outs, but there's a lot of gray area. 2) Will the Applications be something official that you have to nominate modules for and follow certain rules like our release procedures? A big part of what makes applications in the desktop so great is that they work with our translation, documentation, and other teams within our schedule. 3) How strongly will we recommend various applications to our distributors? Please understand that this has a HUGE impact on how we design and write the GNOME 3 help. We want to be able to point to e.g. gucharmap in a topic on entering special characters. Mallard gives us the flexibility to do this even with disparate module sets, but the more ifs and maybes we have to deal with, the harder it is to plan. Thanks, Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Hey, Le mardi 01 juin 2010, à 19:11 -0500, Shaun McCance a écrit : On Wed, 2010-06-02 at 00:37 +0100, Lucas Rocha wrote: Hi all, The release team would like to propose some important changes in the way we organize our modulesets. GNOME releases are currently organized into the following modulesets: Desktop, Platform, Bindings, Mobile, Admin, and Dev Tools. This model has served us well and has actually evolved through time - we didn't have the Admin and Dev Tools modulesets initially. However, we feel that this organization is reaching its limits, and we have explored several potential changes. 1) Do you have a list of what the release team would like to see in the actual Desktop release? There are obvious ins and outs, but there's a lot of gray area. We've been working on that, but indeed, there's a gray area and I think help will be welcome there. I hope we'll be able to refresh a bit the list we have and send it here for review soon. 2) Will the Applications be something official that you have to nominate modules for and follow certain rules like our release procedures? A big part of what makes applications in the desktop so great is that they work with our translation, documentation, and other teams within our schedule. At first, yes, it will be this way. It's the way we've been working for years, so it's easier to do the first step with a process we know. That being said, one rule that, imho, we should remove is that the application is hosted on the GNOME infrastructure -- that's certainly a challenge, especially for translations. But we can't expect to host the whole world in our infrastructure :-) It's important to note that while we want more applications to feel part of GNOME, we also want to encourage them to follow our best practices for the reasons you point out. One idea we've been playing with is some rating for applications, that would be based on how the app respect those best practices. 3) How strongly will we recommend various applications to our distributors? My first reaction to your question is that distributors already choose whatever they want. It's true that our recommendation can make a difference in their decision, though. The way we'll recommend apps is by promoting them, and we'll promote the ones that are good. So they'll likely be picked by distributors because they're good. (I might be naive there, but I'm also a distributor -- sure, I can be a naive distributor ;-)) That being said, can you give an example of where this would be an issue today? The classic one is banshee vs rhythmbox. Or now shotwell vs f-spot vs gthumb. And we don't recommend anything there. Please understand that this has a HUGE impact on how we design and write the GNOME 3 help. We want to be able to point to e.g. gucharmap in a topic on entering special characters. Mallard gives us the flexibility to do this even with disparate module sets, but the more ifs and maybes we have to deal with, the harder it is to plan. I think the example you give might actually give us an answer: if you want to be able to point to gucharmap in the help, then it's an indication that gucharmap might be a good candidate for Desktop. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, 2010-06-02 at 00:37 +0100, Lucas Rocha wrote: The release team would like to propose some important changes in the way we organize our modulesets. It's a shame that this came out almost simultaneously with GNOME 3 module decisions -- as it seems that they are intrinsically tied. For instance, if this was to rejected I'm unsure of what would happen to everything accepted to Applications. That being said, personally I think this going in the right direction. 1. The Desktop moduleset will only contain the components needed to get a desktop session running and provide core functionalities (e.g. gdm, gnome-session, gnome-settings-daemon, nautilus, etc). All applications providing extra relevant features to the desktop (e.g. gedit, Totem, Tomboy, etc) will be moved out from the Desktop moduleset. See the Extra Information section for more details. snip In summary, this means that the GNOME releases would be composed by the following modulesets: - Desktop - Platform - Extended Platform - Mobile I think that there should be a separation between a Desktop module and a Desktop Core module. The Desktop module that should include GNOME Shell, Nautilus, etc. Core would then contain things required to get a basic UI running but without a shell (no panel, just things apps depend on) My intent here is to reflect how the GNOME Desktop is currently being deployed in a couple of cases. I'm thinking of Unity and Meego. In both of these situations we've got basically everything we're talking about in Desktop here: gsd, gnome-session, mutter, etc. But, I don't think either case is planning on adopting GNOME Shell for the netbooks that they're targeted at. This would allow them to be Desktop Core compliant for the applications that need that functionality without having to pull in parts that they aren't going to use. --Ted signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
