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: New module decisions for 3.0
Hi Vincent, On Wed 02 Jun 2010 01:38, Vincent Untz vu...@gnome.org writes: + gjs (desktop) = approved, but with other bindings (not desktop) Does this mean that gjs will follow API/ABI stability guarantees of other parts of the GNOME platform, or of the old Bindings releases? Cheers, Andy -- http://wingolog.org/ ___ 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
GNOME 3.0 Roadmap - Help Needed
Hello GNOME Developers! With the Release Team announcing the GNOME 3.0 moduleset and with GNOME 3.0 now under 4 months away, we need your help! The Marketing team would like to start collecting Roadmap information now (yes, now!) on the new features and benefits to be found in GNOME 3.0, including the Developer Platform and the applications. We have a roadmap[2] for the marketing activities we want to do for the GNOME 3.0 cycle and we need time to create the marketing materials, including a GNOME 3.0 video site, brochures, presentations material and more, and understanding the features that will be present in GNOME 3.0 is critical. No one knows your applications like you do - please help us and add information around the features, benefits and improvements coming in GNOME 3.0. Thanks. Paul [1] http://live.gnome.org/RoadMap [2] http://live.gnome.org/ThreePointZero/MarketingRoadmap ___ 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: GNOME 3.0 Roadmap - Help Needed
We really need a roadmap that goes out past GNOME 3.0 too so please feel free to add information about future releases to the wiki too! Stormy On Wed, Jun 2, 2010 at 5:10 AM, Paul Cutler pcut...@gnome.org wrote: Hello GNOME Developers! With the Release Team announcing the GNOME 3.0 moduleset and with GNOME 3.0 now under 4 months away, we need your help! The Marketing team would like to start collecting Roadmap information now (yes, now!) on the new features and benefits to be found in GNOME 3.0, including the Developer Platform and the applications. We have a roadmap[2] for the marketing activities we want to do for the GNOME 3.0 cycle and we need time to create the marketing materials, including a GNOME 3.0 video site, brochures, presentations material and more, and understanding the features that will be present in GNOME 3.0 is critical. No one knows your applications like you do - please help us and add information around the features, benefits and improvements coming in GNOME 3.0. Thanks. Paul [1] http://live.gnome.org/RoadMap [2] http://live.gnome.org/ThreePointZero/MarketingRoadmap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ 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: New module decisions for 3.0
On Wed, Jun 2, 2010 at 3:46 AM, Andy Wingo wi...@pobox.com wrote: Hi Vincent, On Wed 02 Jun 2010 01:38, Vincent Untz vu...@gnome.org writes: + gjs (desktop) = approved, but with other bindings (not desktop) Does this mean that gjs will follow API/ABI stability guarantees of other parts of the GNOME platform, or of the old Bindings releases? That's a somewhat complex topic. There are multiple layers, I think of them like this: LABI - the C library's ABI IABI - Introspection ABI for given library, what appears in the typelib BABI - Binding ABI, how it processes the IABI to present a language-specific API It's possible for the IABI to break even if the LABI doesn't, when an annotation is added. The best example of this is the (out) annotation. /** * clutter_color_from_pixel: * @color: (out): return location for a #ClutterColor * @pixel: a 32 bit packed integer containing a color * * Converts @pixel from the packed representation of a four 8 bit channel * color to a #ClutterColor. */ void clutter_color_from_pixel (ClutterColor *color, guint32 pixel); Without the (out) annotation, there's no way for introspection to know that the desired GScript API would look like: Clutter.Color.from_pixel(0xffff); Without the annotation though, the function is still *usable*: var color = new Clutter.Color(); color.from_pixel(0xffff); The above is exactly the same as you do in C. For almost all of the introspection annotations though, adding them simply makes functions usable that weren't before; e.g. (element-type Foo) on lists. It's almost really only the (out) case on structures that we need to watch out for. A few others like (type) are used in relatively rare cases such as when an enumeration is *really* an integer. I think what we should say is that after 3.0, libraries should avoid breaking IABI. We need better tools for this, to detect when it's broken. I also suggest to GI-based binding maintainers that the BABI should be treated as frozen after 3.0. ___ 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: New module decisions for 3.0
Hey, On Tue, Jun 1, 2010 at 8:48 PM, Joe Marcus Clarke mar...@freebsd.org wrote: On Tue, 2010-06-01 at 20:20 -0400, Matthias Clasen wrote: On Tue, Jun 1, 2010 at 7:38 PM, Vincent Untz vu...@gnome.org wrote: Hi, + Since we don't have HAL anymore, we need to clearly document what code needs to be ported to various platforms. See the wiki page: http://live.gnome.org/action/diff/TwoPointThirtyone/PortabilityMatrix Just to emphasize this point: it is a wiki page, and we would appreciate contributions to this table, in particular from people who might have first-hand experience in getting GNOME built on non-linux systems. It's good you started this because I was going to comment. The state of things on FreeBSD is as follows: GIO : volume monitoring : works because it uses hal GIO also works even if you don't have HAL because GIO ships with a GUnixVolumeMonitor that works on most Unices even the really obscure ones. Btw, you could also write a GVolumeMonitor implementation that uses FreeBSD specific APIs to enumerate drives, volumes and mounts. g-d-u : does not work as it requires udev Actually, this should be does not work as it requires udisks. The gdu codebase is very careful about not using Linux specific API and even not assuming the udisks daemon is running on the same host - this is why e.g. management of remote hosts http://people.freedesktop.org/~david/gdu-multiple-servers.png just works. IOW, if you have something implementing the udisks API, then gdu and palimpsest will just work. udisks : does not work as it requires udev Actually udisks is designed in a way so it isn't dependent on Linux and so it can be ported to, say, FreeBSD or Solaris. Honestly, it's this way mostly because Linux itself is a very fluid and moving target Anyway, the docs clearly shows this http://hal.freedesktop.org/docs/udisks/ e.g. Linux specific features are clearly marked as such; IOW there's no attempts to abstract what, say, RAID means and then hope that the Linux implementation (using MD RAID) and the FreeBSD implementation (using Vinum) agrees and both fit a common API. Because I don't think that's ever going to work (the best we can hope for is that both OS'es have a notion of block devices). The udisks codebase however isn't currently set up so it's easy to port the udisks codebase to, say, FreeBSD. But I'm planning to at least make that easier, I'm already busy porting it to use GDBus and a big part of that work is cleaning up the separation between the core service and kernel-OS-specific code. The big problem is clearly udev. Last I looked, it was very Linux-centric (i.e. a very thin wrapper on sysfs which FreeBSD does not have). The reason upower came to be on FreeBSD was that someone abstracted the backends, and made it easy to plug in new ones. Say what you will about hal, it had a spec that made it relatively easy to port from platform to platform with some amount of consistency. In FreeBSD we have a device tree which provides a hierarchy of device nodes, but doesn't give too many details about each device. For that, we have to dig a bit deeper (often times requiring root access). For hal, that wasn't a big deal. We could separate privileges, and things worked. I guess udev is started as root by dbus, so that shouldn't be a big deal. What is a big deal is deciding what device nodes to report and what properties of those nodes to advertise. If there was an abstracted backend API for udev, and a list of common subsystems/devices/properties required, I think it would be possible to integrate the work done in hal. Having backends for udev just doesn't make sense because udev (or sysfs) itself isn't a spec or an abstraction. It's the raw Linux device management API - in a very real sense you are dealing with internal kernel data structures when you peek and poke around in sysfs either directly or indirectly via libudev / libgudev1. So it might be easier just to run Linux instead of trying to emulate it David ___ 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: New module decisions for 3.0
On 2 June 2010 17:37, David Zeuthen zeut...@gmail.com wrote: The udisks codebase however isn't currently set up so it's easy to port the udisks codebase to, say, FreeBSD. But I'm planning to at least make that easier, I'm already busy porting it to use GDBus and a big part of that work is cleaning up the separation between the core service and kernel-OS-specific code. The time between me adding the required separation and Makefile glue and the FreeBSD UPower backend getting merged was a matter of weeks. I think it's a classic case of taking the time for the first step and then asking people to fill in the blanks. 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, 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: New module decisions for 3.0
Hey, On Wed, Jun 2, 2010 at 2:23 PM, Richard Hughes hughsi...@gmail.com wrote: On 2 June 2010 17:37, David Zeuthen zeut...@gmail.com wrote: The udisks codebase however isn't currently set up so it's easy to port the udisks codebase to, say, FreeBSD. But I'm planning to at least make that easier, I'm already busy porting it to use GDBus and a big part of that work is cleaning up the separation between the core service and kernel-OS-specific code. The time between me adding the required separation and Makefile glue and the FreeBSD UPower backend getting merged was a matter of weeks. I think it's a classic case of taking the time for the first step and then asking people to fill in the blanks. While there's some truth to that, storage is generally much than system-wide power management - for example, non-Linux udisks backends will have to supply filesystem and partition table routines themselves. And getting it wrong can lead to nasty data corruption disasters etc etc. David ___ 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
