Re: Moduleset Reorganization -- Take two
On 03/15/2011 05:19 PM, Petr Kovar wrote: Jason D. Clintonm...@jasonclinton.com, Mon, 14 Mar 2011 15:28:08 -0500: (...) Beginning in the next few days the Marketing Team will select applications to feature for the 3.0 release. The criteria will be the following: 1. Quality 2. Solving a popular problem 3. GNOME-iness 4. Bonus points for cross-platform-iness For me, a quality GNOME application means that its development process is predictable, scheduled to same degree, and providing translators and/or documentation writers necessary time period of string freeze. Furthermore, GNOME-iness to me means that an application developer is open to the idea of collaborating with the GNOME Translation Project, whether it's our community effort to have unified l10n workflow as far as GNOME applications are concerned, possibility to foster translation consistency among GNOME applications, or at least to have a communicative and responsive application maintainer who doesn't regard translators to be second class citizens in the application development processes. So if you are prepared to give bonus points for cross-platform-iness (nothing against that), why not consider giving bonus points for something that has been one of the principal goals of the GNOME Project for quite some time, that is i18n/l10n? Yet there are other important GNOME aims like a11y, but perhaps that is already included in that Quality part? Very good point! Bringing accessibility to computing regardless of physical or mental abilities or language is a critical part of our mission and it's a standard that we should expect from our applications. These matters should weight in heavily when selecting the apps we promote on the website the coming months. Thanks, may I suggest that gnome-i18n members (or a person delegated by them) could take part in the decission process then? That would possibly make the situation clearer, more transparent to the GNOME translation community, and, needless to say, for the benefit of the GNOME international end-users. Sure, sounds like a very good idea! - Andreas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On Tue, Feb 1, 2011 at 02:47, Frederic Peters fpet...@gnome.org wrote: Too slow probably, so after discussing things at the Boston Summit, new modulesets written by Jon McCann[1] were pushed, those were certainly close to what the release team envisoned, but they also had their share of problems, and the release team, and other teams, had to follow suit, fixing both those new sets, and the various tools that had been broken in the change. Hi everyone! I bet you were hoping you'd never see another email on this thread! ;-) For everyone's reference, the defined modulesets are here: http://git.gnome.org/browse/jhbuild/tree/modulesets But that's not what this email is about. This email is as much as follow-up to this thread as it is a follow-up to the Summit discussion documented here http://jasondclinton.livejournal.com/82450.html. Specifically, the argument over Featured Applications. At the time, after the session, Vincent, Ryan Lortie, and I spoke some more and I proposed a compromise which they both liked: Release Team continue to administer the formal new module proposal process for Core (that is, everything which would be considered part of GNOME OS and is currently in the Core moduleset) and external dependencies process as they are handled today and Marketing Team would select applications from the entire GNOME ecosystem to feature in marketing materials as a means by which to promote application quality and our ecosystem. There had been no further communication between us about this proposal until today. Today, representatives from the Marketing Team (Andreas, Allan and myself) and Vincent, representing the Release Team, discussed this because it is time to select featured applications for 3.0's marketing. We agreed to move forward with this proposal. Beginning in the next few days the Marketing Team will select applications to feature for the 3.0 release. The criteria will be the following: 1. Quality 2. Solving a popular problem 3. GNOME-iness 4. Bonus points for cross-platform-iness Our goal is simply to promote the GNOME ecosystem in any manner that makes sense from a marketing perspective. Being a featured application is transient, canonically maintained as a list that happens to be live on our web sites at any given moment, and not particularly a badge of honor to be fought over or bandied about from a module's perspective. (It is not a statement that it is *the* GNOME app. of any particular function.) It merely reflects the Marketing Team's feelings about the application’s status on the above 4 criteria. And obviously, marketing being visually dominated, visual things are likely to get more attention. Marketing Team will look at (and build from source with jhbuild!) first applications which appear in the apps moduleset defined above but we may look outside the jhbuild modulesets. New projects or new application module maintainers are encouraged to continue to go through the process of having their application included in the jhbuild moduleset by the normal means (Bugzilla) to make it easier for us to screenshot. We are not making any judgments about political things like the locations of the project hosting. For example, we all agree that Simple Scan, though hosted on LaunchPad, is going to be a featured application. Also, we all agree that both Banshee and Rhythmbox are excellent applications which will both be featured. There's no reason to select just one. In the meeting today we did not address the concern of translator attention which was raised at the Summit but my personal feelings on the matter are that translators will continue, as they always have, to translate those modules which are popular regardless of whether they are featured or not. To make it absolutely clear, the list of featured applications is that list which is featured on the web at any particular moment. There’s no formal add or remove process except that normal process by which marketing is done. People interested in having their application featured are always welcome to mail the marketing-list to bring something new to our attention. Marketing Team, now more than ever, could use volunteers and is always open to additional members. If you’re interested in joining the Marketing Team, hop on IRC and join #marketing and join the mailing list; we’d love the help. One final note: at this point this is going to be JFDI by the Marketing Team but we are always interested in hearing the GNOME Community’s feedback. Please direct any comments or questions that you have to marketing-list (note the CC). Thanks for making so many awesome applications to choose from! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Andy Wingo wrote: GNOME has done really well with libraries. It would be good to continue to extend this rigor to language bindings. Regardless of the ultimate decision -- NB, not being discussed at language-bindi...@gnome.org -- the lack of communication from the release team is lamentable. I agree, and it's painful to see this from the inside as well; but things are as they are, and getting fixed, slowly. About bindings, not much will change compared to GNOME 2, same API and ABI guidelines, same schedule, etc. but this still need to be written down properly. Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Johannes Schmid wrote: Am Montag, den 31.01.2011, 22:03 +0100 schrieb Frederic Crozat: And this kind of attitude is the best way to ensure people will leave release-team.. Before blaming release-team for all the GNOME deficiencies in GNOME 3, maybe you should check who did the clean-up in the first place. Sorry but I feel this is the wrong attitude for this kind of discussion. Sure, but I understand it, the thing is that the release team has been very careful, drafting proposals, listening to feedback, with regards to a moduleset reorganisation, sure that was slow. Too slow probably, so after discussing things at the Boston Summit, new modulesets written by Jon McCann[1] were pushed, those were certainly close to what the release team envisoned, but they also had their share of problems, and the release team, and other teams, had to follow suit, fixing both those new sets, and the various tools that had been broken in the change. Apart missing modules a big aspect of those modulesets was the absence of a platform, because (as I understand it) he believes it's too early to define a platform, that it makes little sense out of a GNOME OS. After the latest release team meeting I added back a fairly small platform (basically the GNOME 2 platform minus the deprecated libraries, with same API/ABI rules), and a first draft of an extended platform, as discussed on this list. Then this will be written down properly on the wiki, announced on this list, etc. Summary is that is was slow *but* rushed, which is not a good combination, and left people frustrated. Frederic [1] not a member of the release team, this is in part where Frederic is frustrated, if I'm not mistaken ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On Tue, 2011-01-25 at 12:43 +0100, Murray Cumming wrote: On Tue, 2011-01-25 at 10:03 +0100, Frederic Peters wrote: Murray Cumming wrote: What is happening? Maintainers deserve to know. Taking just the bindings, for example, you seem to have done this without bothering to inform the affected maintainers - Dropped all bindings apart from C++ (gtkmm and co). - And volunteered gtkmm for slightly stronger API/ABI and release-frequency rules. Will the release-team please reply. Sorry this is something I have to do and have been to busy at work there last days. But to precisely answer your questions: Thanks. - the bindings have not been dropped, there is C++, there is Python (which is now just pygobject + introspection), there is JS (twice), there is no C# (but http://live.gnome.org/GNOME+MonoHackfest2010 has a plan), there is no Perl or Java, but they were not in the previous modulesets either Yes, they were :http://live.gnome.org/TwoPointTwentynine/Bindings (and not being in the jhbuild modulesets didn't mean not being released alongside GNOME, for the Perl bindings).http://live.gnome.org/TwoPointTwentynine/Bindings This reminds me. I really don't like that the current module lists seem to be just links to the jhbuild XML files: http://live.gnome.org/TwoPointNinetyone/#Release_Suites The list should provide clarity to _humans_, so this isn't good enough. Even without this vague reorganization, at the best of times, we have enough confusion about what is in the official GNOME module sets. - there is no stronger API/ABI rules, but it's true we'd like to have gtkmm follow the schedule. So, I'm free to do an ABI at gtkmm 3.2, for instance, as I was before? You don't seem to link now to _any_ rules for _any_ module sets at the moment, so you aren't communicating any guarantees to the world about API/ABI. The internets can now make up any nonsense and nobody can point them at the truth. I am generally upset about the whole thing, because I helped make things clearer when I was on the release-team. Don't expect me to follow any rules that you can't be bothered to tell me. At the moment I don't consider gtkmm to be in any GNOME module set anymore. I see no real GNOME release process any more. -- 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: Moduleset Reorganization -- Take two
On Mon 31 Jan 2011 14:59, Murray Cumming murr...@murrayc.com writes: - there is no stronger API/ABI rules, but it's true we'd like to have gtkmm follow the schedule. I am also surprised at the lack of rules here, and additionally, the lack of discussion. Without the rules, it's just languages that people like or see as strategic for some reason, and is disrespectful of those bindings that chose to follow the 2.x bindings moduleset. (Guile was not one of them, FWIW.) GNOME has done really well with libraries. It would be good to continue to extend this rigor to language bindings. Regardless of the ultimate decision -- NB, not being discussed at language-bindi...@gnome.org -- the lack of communication from the release team is lamentable. Andy -- http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
2011/1/31 Andy Wingo wi...@pobox.com: On Mon 31 Jan 2011 14:59, Murray Cumming murr...@murrayc.com writes: - there is no stronger API/ABI rules, but it's true we'd like to have gtkmm follow the schedule. I am also surprised at the lack of rules here, and additionally, the lack of discussion. Without the rules, it's just languages that people like or see as strategic for some reason, and is disrespectful of those bindings that chose to follow the 2.x bindings moduleset. (Guile was not one of them, FWIW.) GNOME has done really well with libraries. It would be good to continue to extend this rigor to language bindings. Regardless of the ultimate decision -- NB, not being discussed at language-bindi...@gnome.org -- the lack of communication from the release team is lamentable. And this kind of attitude is the best way to ensure people will leave release-team.. Before blaming release-team for all the GNOME deficiencies in GNOME 3, maybe you should check who did the clean-up in the first place. -- Frederic Crozat who is more and more thinking of dropping his RT hat.. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Hi! Am Montag, den 31.01.2011, 22:03 +0100 schrieb Frederic Crozat: And this kind of attitude is the best way to ensure people will leave release-team.. Before blaming release-team for all the GNOME deficiencies in GNOME 3, maybe you should check who did the clean-up in the first place. Sorry but I feel this is the wrong attitude for this kind of discussion. The release-team made a proposal for the module reorganisation and I think everybody is thankful for it. Basically the proposal was to reduce the official release-set to core components and bindings while putting other applications in Applications release-set. This was mostly done to reduce the workload on the release-team and to keep the release process manageable. However, after this proposal there was and still is no formal announcement of the new release-sets. The answer until know was that the current status is reflected by the jhbuild sets but could still be changed. I think it is more than reasonable that people expect a formal definition of the release-sets with a wiki page [1] together with listing the requirements and guarantees for each set. I would also be nice to define what is in the Applications set now. And you must admit that it is not polite to move modules to different sets with new rules without asking the maintainers. Nevertheless, nobody wants to blame the release-team for doing everything wrong because a reorganization was definitely needed but it would just be nice if it would be completed now that we reach beta state soon. Regards, Johannes [1] http://live.gnome.org/TwoPointNinetyone 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: Moduleset Reorganization -- Take two
On Mon 31 Jan 2011 22:03, Frederic Crozat f...@crozat.net writes: 2011/1/31 Andy Wingo wi...@pobox.com: Regardless of the ultimate decision -- NB, not being discussed at language-bindi...@gnome.org -- the lack of communication from the release team is lamentable. And this kind of attitude is the best way to ensure people will leave release-team.. I'm sorry, that was not my intention at all. You all are doing a lot of great work. As for myself, I'm doing none; so apologies there, and kudos to you. However, there was a procedure in place before. Murray headed it up. It seemed mostly sensible, though a bit strict. Change is fine, but it seems like we're just slipping into it instead of choosing it; at least that's my perspective, as a bindings author. Best regards, Andy -- http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Murray Cumming wrote: What is happening? Maintainers deserve to know. Taking just the bindings, for example, you seem to have done this without bothering to inform the affected maintainers - Dropped all bindings apart from C++ (gtkmm and co). - And volunteered gtkmm for slightly stronger API/ABI and release-frequency rules. Will the release-team please reply. Sorry this is something I have to do and have been to busy at work there last days. But to precisely answer your questions: - the bindings have not been dropped, there is C++, there is Python (which is now just pygobject + introspection), there is JS (twice), there is no C# (but http://live.gnome.org/GNOME+MonoHackfest2010 has a plan), there is no Perl or Java, but they were not in the previous modulesets either (and not being in the jhbuild modulesets didn't mean not being released alongside GNOME, for the Perl bindings). - there is no stronger API/ABI rules, but it's true we'd like to have gtkmm follow the schedule. Sorry again for being this slow, Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On Tue, 2011-01-25 at 10:03 +0100, Frederic Peters wrote: Murray Cumming wrote: What is happening? Maintainers deserve to know. Taking just the bindings, for example, you seem to have done this without bothering to inform the affected maintainers - Dropped all bindings apart from C++ (gtkmm and co). - And volunteered gtkmm for slightly stronger API/ABI and release-frequency rules. Will the release-team please reply. Sorry this is something I have to do and have been to busy at work there last days. But to precisely answer your questions: Thanks. - the bindings have not been dropped, there is C++, there is Python (which is now just pygobject + introspection), there is JS (twice), there is no C# (but http://live.gnome.org/GNOME+MonoHackfest2010 has a plan), there is no Perl or Java, but they were not in the previous modulesets either Yes, they were :http://live.gnome.org/TwoPointTwentynine/Bindings (and not being in the jhbuild modulesets didn't mean not being released alongside GNOME, for the Perl bindings).http://live.gnome.org/TwoPointTwentynine/Bindings This reminds me. I really don't like that the current module lists seem to be just links to the jhbuild XML files: http://live.gnome.org/TwoPointNinetyone/#Release_Suites The list should provide clarity to _humans_, so this isn't good enough. Even without this vague reorganization, at the best of times, we have enough confusion about what is in the official GNOME module sets. - there is no stronger API/ABI rules, but it's true we'd like to have gtkmm follow the schedule. So, I'm free to do an ABI at gtkmm 3.2, for instance, as I was before? You don't seem to link now to _any_ rules for _any_ module sets at the moment, so you aren't communicating any guarantees to the world about API/ABI. The internets can now make up any nonsense and nobody can point them at the truth. I am generally upset about the whole thing, because I helped make things clearer when I was on the release-team. -- 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: Moduleset Reorganization -- Take two
On Mon, 2011-01-03 at 15:57 +0100, Murray Cumming wrote: On Mon, 2011-01-03 at 15:52 +0100, Murray Cumming wrote: On Thu, 2010-11-18 at 13:53 +0100, Kenneth Nielsen wrote: I'm interested to know what is going to happen about the module set reorganization now. We had the second proposal presented, we had a HUGE discussion about pros and cons with a lot of different views on this. So now what? - Will this be implemented? - If so when? - Or will there be another iteration with another proposal and discussion? [snip] I am also very concerned that there has been no further announcement about this, and no response to the concerns raised, though the recent releases show at least some, though not all, of these changes. What is happening? Maintainers deserve to know. Taking just the bindings, for example, you seem to have done this without bothering to inform the affected maintainers - Dropped all bindings apart from C++ (gtkmm and co). - And volunteered gtkmm for slightly stronger API/ABI and release-frequency rules. Will the release-team please reply. -- 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: Moduleset Reorganization -- Take two
On Thu, 2010-11-18 at 13:53 +0100, Kenneth Nielsen wrote: I'm interested to know what is going to happen about the module set reorganization now. We had the second proposal presented, we had a HUGE discussion about pros and cons with a lot of different views on this. So now what? - Will this be implemented? - If so when? - Or will there be another iteration with another proposal and discussion? [snip] I am also very concerned that there has been no further announcement about this, and no response to the concerns raised, though the recent releases show at least some, though not all, of these changes. What is happening? Maintainers deserve to know. -- 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: Moduleset Reorganization -- Take two
On Mon, 2011-01-03 at 15:52 +0100, Murray Cumming wrote: On Thu, 2010-11-18 at 13:53 +0100, Kenneth Nielsen wrote: I'm interested to know what is going to happen about the module set reorganization now. We had the second proposal presented, we had a HUGE discussion about pros and cons with a lot of different views on this. So now what? - Will this be implemented? - If so when? - Or will there be another iteration with another proposal and discussion? [snip] I am also very concerned that there has been no further announcement about this, and no response to the concerns raised, though the recent releases show at least some, though not all, of these changes. What is happening? Maintainers deserve to know. Taking just the bindings, for example, you seem to have done this without bothering to inform the affected maintainers - Dropped all bindings apart from C++ (gtkmm and co). - And volunteered gtkmm for slightly stronger API/ABI and release-frequency rules. -- 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: Moduleset Reorganization -- Take two
From: Murray Cumming murr...@murrayc.com On Mon, 2011-01-03 at 15:52 +0100, Murray Cumming wrote: On Thu, 2010-11-18 at 13:53 +0100, Kenneth Nielsen wrote: I'm interested to know what is going to happen about the module set reorganization now. We had the second proposal presented, we had a HUGE discussion about pros and cons with a lot of different views on this. So now what? - Will this be implemented? - If so when? - Or will there be another iteration with another proposal and discussion? [snip] I am also very concerned that there has been no further announcement about this, and no response to the concerns raised, though the recent releases show at least some, though not all, of these changes. What is happening? Maintainers deserve to know. Taking just the bindings, for example, you seem to have done this without bothering to inform the affected maintainers - Dropped all bindings apart from C++ (gtkmm and co). - And volunteered gtkmm for slightly stronger API/ABI and release-frequency rules. As I noted some weeks ago [1], this is also the case for Orca and Accerciser. Both were dropped without a warning to their maintainers (and as I said on the mail, on both cases, IMHO, they both fit without problem on the Applications moduleset). This is somewhat disturbing. And although probably the interested people could be blamed because they are not subscribed to release team mailing list, if you take a look to the release planning [2], there are a point to Module inclusion discussion heats up, but nothing about module dropping. So, a maintainer that have a module included, by default will suppose that his module will not be dropped by the release machinery. BR [1] http://mail.gnome.org/archives/desktop-devel-list/2010-December/msg00116.html [2] http://live.gnome.org/TwoPointNinetyone === API (apinhe...@igalia.com) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Piñeiro wrote: As I noted some weeks ago [1], this is also the case for Orca and Accerciser. I guess the holiday season made both Jon and Matthias away from their computers; as they pushed the new modulesets I would have loved to have their answers to this thread, instead of ignoring them and adding those modules back to the modulesets. This is somewhat disturbing. And although probably the interested people could be blamed because they are not subscribed to release team mailing list, if you take a look to the release planning [2], there They certainly can't be blamed, the release team list archives are public, but only the release team members are subscribed. Cheers, Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
From: Frederic Peters fpet...@gnome.org Piñeiro wrote: As I noted some weeks ago [1], this is also the case for Orca and Accerciser. I guess the holiday season made both Jon and Matthias away from their computers; as they pushed the new modulesets I would have loved to have their answers to this thread, instead of ignoring them and adding those modules back to the modulesets. No problem, I already supposed that holidays affected the low response of that thread. This is somewhat disturbing. And although probably the interested people could be blamed because they are not subscribed to release team mailing list, if you take a look to the release planning [2], there They certainly can't be blamed, the release team list archives are public, but only the release team members are subscribed. Ok, I didn't know that (although it is explained here [1]). Thanks for the information. BR [1] http://mail.gnome.org/mailman/listinfo/release-team === API (apinhe...@igalia.com) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Bump 2010/11/18 Kenneth Nielsen k.nielse...@gmail.com: I'm interested to know what is going to happen about the module set reorganization now. We had the second proposal presented, we had a HUGE discussion about pros and cons with a lot of different views on this. So now what? - Will this be implemented? - If so when? - Or will there be another iteration with another proposal and discussion? I'm asking because this could potentially means some changes in tools and work flows for translators, so I just want to make sure that it is not something that will be dropped on us during the last month before the release of GNOME 3.0, where (a) we have plenty to do and (b) we definitely want to make sure that we are all running at peak efficiency, so we don't end up with a KDE 4.0 like release ;) Regards Kenneth ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
I'm interested to know what is going to happen about the module set reorganization now. We had the second proposal presented, we had a HUGE discussion about pros and cons with a lot of different views on this. So now what? - Will this be implemented? - If so when? - Or will there be another iteration with another proposal and discussion? I'm asking because this could potentially means some changes in tools and work flows for translators, so I just want to make sure that it is not something that will be dropped on us during the last month before the release of GNOME 3.0, where (a) we have plenty to do and (b) we definitely want to make sure that we are all running at peak efficiency, so we don't end up with a KDE 4.0 like release ;) Regards Kenneth ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Hi! El dg 10 de 10 de 2010 a les 01:41 +0200, en/na Petr Kovar va escriure: Hi! Michael Terry m...@mterry.name, Fri, 8 Oct 2010 10:30:14 -0400: On 8 October 2010 03:13, Johannes Schmid j...@jsschmid.de wrote: The best solution IMHO would be to import PO files for all applications, and integrate them into Damned Lies. Else, we're taking the risk of losing consistency, and « moduleset » won't mean anything in the end. I am afraid that the problem is not to import PO files in damned-lies but to commit them from damned-lies to the repositories. And we have to find a solution for this while keeping the current permissions that are specific to git.gnome.org. From a Launchpad perspective, a translation branch can be imported from git into a bzr branch in Launchpad. This would involve zero change from an LP maintainer perspective (currently, there is a bzr branch in LP for translations that gets written to by translators through the web interface; maintainers merge that branch before a release). So the trick then would be having Damned Lies import pot/po files from a bzr trunk. Then GNOME translators can edit them in git like they like. Then LP can import that translation branch with changes. Eh? I think that would be very acceptable to GNOME translators, while keeping the main development at a location of developer's preference. (CC'ing gnome-i18n as this is definitely of interest to the members of that group as well.) Best, Petr Kovar ___ gnome-i18n mailing list gnome-i...@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n Being a module on the applications moduleset should be a coin with its two sides: being famous as an application in a GNOME official set but some requirements as explained in the propuse sent by Vincent. As Emmanuele already said on the thread discussing Clutter translations[1] one way to go could be creating not-official repositories on GNOME infrastructure synchronized wit the official one where the GNOME i18n can send their translations and the module developers should only have to pull from. With translations the VCS used is not that important since the last translation is the important so the developer could just grab the po folder and put on their VCS. That way translators can keep their focus on translating and not going through different systems to send the translations, but also since everything would be in one place more nice things could be created (automatic fuzzies for strings already translated on other modules, glossaries, translation memories, an API to query translation status and update them...). If we deliver a rock solid GNOME 3.0 but with all kind of mistranslations everywhere no one would use it. Cheers, [1] http://mail.gnome.org/archives/gnome-i18n/2010-October/msg00016.html -- gil forcada [ca] guifi.net - una xarxa lliure que no para de créixer [en] guifi.net - a non-stopping free network bloc: http://gil.badall.net planet: http://planet.guifi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Hi! Kenneth Nielsen k.nielse...@gmail.com, Thu, 14 Oct 2010 10:34:13 +0200: (...) If I give it my best at being a little frexible, I think we can make it work from a l10n point of view. The key is information and overviews. I think not everybody understands just exactly how important damned lies like functionality is to us translators and how much we use it. The reason is that we usually touch a lot more modules than any other contributor group. We frequently browse through lists to find work and access progress. So if... the Apps module set will have its own page in damned lies and if... string freeze and release dates are present there on that overview list, for the apps that don't follow the GNOME release schedule, and if the number of those apps are kept low, then I think that is still a workable solution. If asynced release schedules eventually become reality for official GNOME modules wherever they might be hosted (I still hope it's avoidable, though), I think many GNOME translators would really appreciate having the following as a hard requirement: * string freeze period lasting for a reasonable amount of time (some might think that having a string freeze for two days is enough, well, it is not), * string freeze break requests handled the same way that it is now, * release schedule presented on a special overview page at our l10n infrastructure, timely (as Kenneth writes; probably less suitable way would be to announce it to the gnome-i18n mailing list, as it is done now voluntarily by some enlightened maintainers of unofficial modules (thank you!). Surely, having no synced schedule is barely an improvement for l10n support. Among other things, translators would be unable to do some common changes (e.g. terminology or QA fixes) throughout moduleset in one step just before the stable (or development) release. My 33 hellers, Petr Kovar ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Hi! And many of these modules have very little to do with each other and very little reason to be forced into the same schedule. Can you give us a list of actual modules that will no longer be on the release schedule, please? That would help me judge the actual effect. I don't see how this proposal would solve this. Everything in Application will still be following the release-cycle (except very few modules) and would still be handled by the release team. Otherwise you could simply propose that all non-core modules are dropped from the release-set but this isn't what the proposal says. It is time to cut back and focus on the core desktop a bit more, and let the wider set of apps run a little more freely. So all the core modules (Stable Platform, Core Desktop) must be on the release schedule? That's at least reassuring. see above! That needs clarification because it is NOT what the proposal is currently saying. Also, I generally think that you are making it hard for people to judge this proposal by unnecessarily grouping several changes together, though they don't need to all happen at once. +1 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: Moduleset Reorganization -- Take two
On Thu, 2010-10-07 at 13:38 +0200, Vincent Untz wrote: System Platform === The System Platform is the set of libraries or dbus services that are used in GNOME, but are modules belonging to lower parts of the stack. We encourage their use for GNOME applications. This set might change over the years, and API/ABI stability is up to the respective developers. However, we will encourage them to guarantee stability. Candidates for this set include: ConsoleKit, NetworkManager, Xorg, avahi, bluez, cairo, dbus, geoclue, gudev, libxml, pulseaudio, udisks, upower. How is this different to the existing External Dependencies? If it's just a name change then it doesn't seem worth doing or mentioning. -- 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: Moduleset Reorganization -- Take two
On Fri, Oct 15, 2010 at 11:21 AM, Murray Cumming murr...@murrayc.com wrote: On Thu, 2010-10-07 at 13:38 +0200, Vincent Untz wrote: System Platform === The System Platform is the set of libraries or dbus services that are used in GNOME, but are modules belonging to lower parts of the stack. We encourage their use for GNOME applications. This set might change over the years, and API/ABI stability is up to the respective developers. However, we will encourage them to guarantee stability. Candidates for this set include: ConsoleKit, NetworkManager, Xorg, avahi, bluez, cairo, dbus, geoclue, gudev, libxml, pulseaudio, udisks, upower. How is this different to the existing External Dependencies? If it's just a name change then it doesn't seem worth doing or mentioning. System platform are things that we assume are present, and which do not make sense to build e.g. as part of a jhbuild moduleset. Why do you think clarification of that is not worth doing ? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On Fri, 2010-10-15 at 17:21 +0200, Murray Cumming wrote: On Thu, 2010-10-07 at 13:38 +0200, Vincent Untz wrote: System Platform === The System Platform is the set of libraries or dbus services that are used in GNOME, but are modules belonging to lower parts of the stack. We encourage their use for GNOME applications. This set might change over the years, and API/ABI stability is up to the respective developers. However, we will encourage them to guarantee stability. Candidates for this set include: ConsoleKit, NetworkManager, Xorg, avahi, bluez, cairo, dbus, geoclue, gudev, libxml, pulseaudio, udisks, upower. How is this different to the existing External Dependencies? If it's just a name change then it doesn't seem worth doing or mentioning. My understanding is that these are the technologies that we actively encourage developers to use. The external dependencies are then just those that we happen to use internally. This is actually really useful to those of us working on developer documentation, and especially for me updating the Platform Overview. If you're in the System Platform, you're in the Overview. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On Fri, 2010-10-15 at 11:33 -0400, Shaun McCance wrote: On Fri, 2010-10-15 at 17:21 +0200, Murray Cumming wrote: On Thu, 2010-10-07 at 13:38 +0200, Vincent Untz wrote: System Platform === The System Platform is the set of libraries or dbus services that are used in GNOME, but are modules belonging to lower parts of the stack. We encourage their use for GNOME applications. This set might change over the years, and API/ABI stability is up to the respective developers. However, we will encourage them to guarantee stability. Candidates for this set include: ConsoleKit, NetworkManager, Xorg, avahi, bluez, cairo, dbus, geoclue, gudev, libxml, pulseaudio, udisks, upower. How is this different to the existing External Dependencies? If it's just a name change then it doesn't seem worth doing or mentioning. My understanding is that these are the technologies that we actively encourage developers to use. The external dependencies are then just those that we happen to use internally. Ah. That's a very useful distinction then. Sorry. This is actually really useful to those of us working on developer documentation, and especially for me updating the Platform Overview. If you're in the System Platform, you're in the Overview. -- 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: Moduleset Reorganization -- Take two
On Wed, 2010-10-13 at 09:21 -0400, Matthias Clasen wrote: On Wed, Oct 13, 2010 at 3:15 AM, Murray Cumming murr...@murrayc.com wrote: Then I think your proposal will be a complete disaster. I'm horrified that we must again justify the existence of a shared release schedule and of a release-team that keeps modules on that schedule. This is little more than killing the GNOME release process just because you have forgotten why we needed it in the first place. A bit dramatic today, are we ? See, what we have today is an ever-growing set of modules (200 !), Not including external dependencies? that is almost impossible to get to build at any given time. When modules don't even build, that's generally a sign that they need _more_ release process, to provide more stability, not less. Those modules' problems won't be fixed by ignoring those modules, though it will make the release-team's life easier. And many of these modules have very little to do with each other and very little reason to be forced into the same schedule. Can you give us a list of actual modules that will no longer be on the release schedule, please? That would help me judge the actual effect. Note also that you are actually suggesting _adding_ the many Platform Bindings modules to the Platform, which will require even _more_ work for you. I am not confident that you will make the bindings stick to these stricter rules given that the release-team has failed to make them stick to the current looser Platform Bindings rules. It is time to cut back and focus on the core desktop a bit more, and let the wider set of apps run a little more freely. So all the core modules (Stable Platform, Core Desktop) must be on the release schedule? That's at least reassuring. If we didn't want to make any changes, we could just continue to do GNOME 2.x until we all retire... I don't see how GNOME 3.x fundamentally requires this change of release-process. Also, I generally think that you are making it hard for people to judge this proposal by unnecessarily grouping several changes together, though they don't need to all happen at once. -- 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: Moduleset Reorganization -- Take two
2010/10/12 Sandy Armstrong sanfordarmstr...@gmail.com: On Tue, Oct 12, 2010 at 1:31 PM, Murray Cumming murr...@murrayc.com wrote: On Tue, 2010-10-12 at 15:03 +0200, Vincent Untz wrote: Good point. It's fair to expect projects not using the GNOME development cycle to publish a schedule with freezes. You would allow modules in the module sets that don't follow the GNOME schedule? Then it loses all meaning. Once again, the purpose of the release schedule (of which the module sets are just a part) is to release software. I agree here. I'm not sure how the i18n and docs teams are supposed to do their jobs if they have to track dozens of different schedules. Maybe those teams should only devote resources to an application on the occasion that a release matches up with the GNOME schedule? This would allow for apps to have more or less frequent releases, but at the same time encourage them to have their releases match up with the GNOME schedule whenever possible. I would very much like to give a translators point of view here. I think that reorganising the module sets in some way is a good idea, because right now the current situation has us (translators) unfairly favouritising certain apps because they are part of the dekstop module set. The main thing that I care about, is to provide quality translations of GNOME related software (prioritised on some way after importance and popularity) to users, therefore the present situation where rhythmbox gets a lot more translations love than banshee (because one is part of the grand desktop module set and the other is lumped in with all the others in Extra applications) is far from optimal. I would like to see this resolved in some way. The problem here is off course that some compromises will have to be made. I would like to have all the popular apps gathered somewhere so we know what to focus on, I would also like them to all release following the GNOME schedule, but on the other hand I know that certain popular projects would rather stay out of such a grouping than to conform with our schedule, so something has to give. If I give it my best at being a little frexible, I think we can make it work from a l10n point of view. The key is information and overviews. I think not everybody understands just exactly how important damned lies like functionality is to us translators and how much we use it. The reason is that we usually touch a lot more modules than any other contributor group. We frequently browse through lists to find work and access progress. So if... the Apps module set will have its own page in damned lies and if... string freeze and release dates are present there on that overview list, for the apps that don't follow the GNOME release schedule, and if the number of those apps are kept low, then I think that is still a workable solution. Regards Kenneth ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
It is time to cut back and focus on the core desktop a bit more, and let the wider set of apps run a little more freely. So all the core modules (Stable Platform, Core Desktop) must be on the release schedule? That's at least reassuring. The option to run on their own schedule is for modules in the new Apps module set only right? \Kenneth ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On Tue, 2010-10-12 at 15:28 +0200, Vincent Untz wrote: This was mentioned later in the proposal: we encourage app developers to follow the GNOME schedule. But if they don't, they need to publish their schedule. We think most people will adopt the GNOME schedule, but some app developers might have different needs. For example, I talked to the Shotwell developers at GUADEC, and they currently use cycles that are much shorter than six months. What matters is that there is a documented schedule, and that there are proper freezes. It doesn't have to be the GNOME schedule, although it's nicer for us. Then I think your proposal will be a complete disaster. I'm horrified that we must again justify the existence of a shared release schedule and of a release-team that keeps modules on that schedule. This is little more than killing the GNOME release process just because you have forgotten why we needed it in the first place. -- 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: Moduleset Reorganization -- Take two
From: Vincent Untz vu...@gnome.org I guess that in this proposal modules like at-spi2-atk or pyatspi2 will be obviously in the Core Desktop, as they are fundamental to the a11y support. Right. Ok But if we move forward toward the line we find Orca: * It is a application = should stay in Applications? * But it one of the basic accessibility modules = should stay in Core Desktop? I don't know a lot about accessibility, but to me, orca is (or at least, was so far -- maybe it will change with a11y integration in the shell?) As this a11y integration in the shell is in the same paragrah that orca, I guess that you are talking about Mathias Clasen comment. So I will do the question again (as Mathias didn't answer my question). Are people proposing to add at-spi2 compliant screen reader with braille support as a gnome-shell feature? What do you understand as integration in the shell? a core part of the desktop for accessibility. It's what most people use to really make the desktop accessible in the way they need. And if we keep moving forward we find Accerciser: * It is a application = should stay in Applications? * But it one of the basic accessibility modules = should stay in Core Desktop? * Well, yes, basic module, but for developers = additional point to move it to Applications? Accerciser, on the other hand, is a tool that is not useful for most people. It's really a tool for developers (so there's no reason for it to be in the Core), so it'd go in Applications. Ok, thanks for the explanation. BR === API (apinhe...@igalia.com) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On Wed, Oct 13, 2010 at 3:15 AM, Murray Cumming murr...@murrayc.com wrote: Then I think your proposal will be a complete disaster. I'm horrified that we must again justify the existence of a shared release schedule and of a release-team that keeps modules on that schedule. This is little more than killing the GNOME release process just because you have forgotten why we needed it in the first place. A bit dramatic today, are we ? See, what we have today is an ever-growing set of modules (200 !), that is almost impossible to get to build at any given time. And many of these modules have very little to do with each other and very little reason to be forced into the same schedule. It is time to cut back and focus on the core desktop a bit more, and let the wider set of apps run a little more freely. If we didn't want to make any changes, we could just continue to do GNOME 2.x until we all retire... Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On Wed, Oct 13, 2010 at 6:21 AM, Piñeiro apinhe...@igalia.com wrote: Are people proposing to add at-spi2 compliant screen reader with braille support as a gnome-shell feature? What do you understand as integration in the shell? What I meant with integration is that it should appear as part of the core desktop experience, not as a separate application. The experience should be: You go to the control-center, turn on screen reader support, and then every part of the desktop is read to you. Not: I start the application 'orca'. Of course, this doesn't necessary mean that the implementation has to live in the gnome-shell process. Anyway, this is more of a medium-term perspective. For 3.0, orca will certainly be there. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On Wed, 2010-10-13 at 09:21 -0400, Matthias Clasen wrote: On Wed, Oct 13, 2010 at 3:15 AM, Murray Cumming murr...@murrayc.com wrote: Then I think your proposal will be a complete disaster. I'm horrified that we must again justify the existence of a shared release schedule and of a release-team that keeps modules on that schedule. This is little more than killing the GNOME release process just because you have forgotten why we needed it in the first place. A bit dramatic today, are we ? See, what we have today is an ever-growing set of modules (200 !), that is almost impossible to get to build at any given time. And many of these modules have very little to do with each other and very little reason to be forced into the same schedule. It is time to cut back and focus on the core desktop a bit more, and let the wider set of apps run a little more freely. the problem which could arise here is, that many apps could loose some of their quality, be it translations, documentation or also programming issues and use of deprecated stuff. have a look at gnomefiles.org or any other conglomeration of gnome-style software and compare that quality to what we have inside gnome. of course, it does not have to come like this, but there is a possibility which i personally would like to avoid. daniel If we didn't want to make any changes, we could just continue to do GNOME 2.x until we all retire... Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net 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: Moduleset Reorganization -- Take two
From: Matthias Clasen matthias.cla...@gmail.com On Wed, Oct 13, 2010 at 6:21 AM, Piñeiro apinhe...@igalia.com wrote: Are people proposing to add at-spi2 compliant screen reader with braille support as a gnome-shell feature? What do you understand as integration in the shell? What I meant with integration is that it should appear as part of the core desktop experience, not as a separate application. The experience should be: You go to the control-center, turn on screen reader support, and then every part of the desktop is read to you. Not: I start the application 'orca'. Of course, this doesn't necessary mean that the implementation has to live in the gnome-shell process. Thanks for the clarification. When Joanmarie and I read it, we thought that you were proposing to move the implementation (due the magnifier example). This proposal has sense, in fact this screen reader on/off is already in the accessibility settings (mockup) recently added (anyway it still be required to use orca to configure things). Anyway, this is more of a medium-term perspective. For 3.0, orca will certainly be there. Of course. Again, thanks for the clarification. BR === API (apinhe...@igalia.com) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Le lundi 11 octobre 2010, à 23:20 +0200, Kenneth Nielsen a écrit : I would like to elaborate on one very important thing that you mention, and that is that if a project chooses not to follow the GNOME release schedule, the key is information. So when/(if) this happens it has to be extremely visibly, preferably right there in l10n.org. So I would suggest as a technical detail to your proposal, that it is a _requirement_ for project maintainers of projects that don't follow the GNOME release schedule, to not only document it in their development fora, but also to publish a (tentative) string freeze and release date somewhere in the repository, so that it can be automatically parsed and published on damned lies. Good point. It's fair to expect projects not using the GNOME development cycle to publish a schedule with freezes. 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: Moduleset Reorganization -- Take two
Le jeudi 07 octobre 2010, à 17:08 +0200, Piñeiro a écrit : From: Johannes Schmid j...@jsschmid.de Hi! Initially, for GNOME 3.0, it will be populated with the modules from the GNOME 2.x Desktop moduleset. However, we would like to slowly migrate some modules to the Applications moduleset. I guess everything related to accessibility will stay in Desktop, right? This is a good question, and I have some doubts, probably because in some cases there are a thin line between Core Desktop and Applications I guess that in this proposal modules like at-spi2-atk or pyatspi2 will be obviously in the Core Desktop, as they are fundamental to the a11y support. Right. But if we move forward toward the line we find Orca: * It is a application = should stay in Applications? * But it one of the basic accessibility modules = should stay in Core Desktop? I don't know a lot about accessibility, but to me, orca is (or at least, was so far -- maybe it will change with a11y integration in the shell?) a core part of the desktop for accessibility. It's what most people use to really make the desktop accessible in the way they need. And if we keep moving forward we find Accerciser: * It is a application = should stay in Applications? * But it one of the basic accessibility modules = should stay in Core Desktop? * Well, yes, basic module, but for developers = additional point to move it to Applications? Accerciser, on the other hand, is a tool that is not useful for most people. It's really a tool for developers (so there's no reason for it to be in the Core), so it'd go in Applications. Cheers, 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: Moduleset Reorganization -- Take two
Le samedi 09 octobre 2010, à 09:25 +0200, Josselin Mouette a écrit : Le jeudi 07 octobre 2010 à 13:38 +0200, Vincent Untz a écrit : API/ABI Stable Platfom == The API/ABI Stable Platfom works in the exact same way as the GNOME 2.x moduleset, but it can also include dbus services that guarantee stability of their dbus interfaces. I’m thrilled to finally see guaranteed ABI stability on D-Bus interfaces. This has been one of the major problems we had to deal with upon upgrades. Unlike shared libraries, t is ver It's worth pointing out that, so far, we have no dbus interface that provides stability guarantees :-) Hopefully, saying that we can have that in the platform will help maintainers decide to od it. The Core Desktop is the set of components that are needed to get a desktop session running and to have it provide core functionalities (display manager, session manager, desktop shell, file manager, settings manager, etc.). Where do you draw the line with some applications that should be part of any desktop, like eog and evince? Right. That's the hard question :-) And that's an issue we have today: how do we define the desktop? Should it include a browser (we chose yes a few years ago), a video player (again, we chose yes), a IM client (we only chose yes recently), a music library (so far, we stayed with no, but nearly all users use one). I know Jon has been thinking about this and proposed a list of core utilities that included some tools. We do need help to take a decision here. + we strongly encourage the application developers to follow the GNOME development cycle. If a different development cycle is used, it has to be documented to help contributors. Without that, how do you decide, at the time of the release, which version of the application will go into the release? If a different development cycle is used, it has to be documented (as mentioned). So we can know what will be the stable version at the time of the GNOME release, and therefore which version can be used. Or am I missing something? This is not an innocent question; when something changes (often in an incompatible way) in the extended platform, you need to ensure that all applications work consistently with it. Nod. Which is why most people will just use the GNOME cycle anyway ;-) I mean this issue already exists as of today with applications that are not blessed by GNOME, and it works fine in the end, doesn't it? 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: Moduleset Reorganization -- Take two
Le jeudi 07 octobre 2010, à 16:50 +0200, Murray Cumming a écrit : On Thu, 2010-10-07 at 13:38 +0200, Vincent Untz wrote: + feedback will not be centered around the goal of the application, but about its technical merits: - use of GNOME technologies - integration with the Core Desktop - usability and respect of the HIG - existence of localization issues or not - status of documentation - accessibility support But you will still require these modules to actually follow the release schedule, right, such as feature freezes, string freezes, UI freezes, hard-code freeze, etc? This was mentioned later in the proposal: we encourage app developers to follow the GNOME schedule. But if they don't, they need to publish their schedule. We think most people will adopt the GNOME schedule, but some app developers might have different needs. For example, I talked to the Shotwell developers at GUADEC, and they currently use cycles that are much shorter than six months. What matters is that there is a documented schedule, and that there are proper freezes. It doesn't have to be the GNOME schedule, although it's nicer for us. The point of the release sets (and the release team) is still to release software, I hope. Sure. And the way it works wouldn't change for the platform and the core desktop. But for applications, the way we work would need to be adjusted a bit. 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: Moduleset Reorganization -- Take two
On Tue, Oct 12, 2010 at 9:22 AM, Vincent Untz vu...@gnome.org wrote: Where do you draw the line with some applications that should be part of any desktop, like eog and evince? Right. That's the hard question :-) And that's an issue we have today: how do we define the desktop? Should it include a browser (we chose yes a few years ago), a video player (again, we chose yes), a IM client (we only chose yes recently), a music library (so far, we stayed with no, but nearly all users use one). I don't think thats quite the right question to ask. Obviously, a complete desktop needs to provide a browser and a video player and an IM client. But that does not mean that those are part of the core desktop infrastructure. They are just essential applications that no desktop can do without. The right question to ask when deciding if something is an application or part of the core are - does it have an individual identity or branding (one indication here is whether it uses a generic name or a branded name, think 'GNOME character map' vs. 'gEdit') - does it provide tightly integrated services througout the desktop (e.g cd burning inside rhythmbox and nautilus) or is it a standalone thing ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Hi Vincent, I still have mixed feelings about the proposed moduleset reorganization, though I think it is definitely better than the original proposal. It seems to me that we are pretty much just ratifying our inability to actually make choices... distros will just ship one music player, one browser etc. Anyway for now I'd like to concentrate on a separate point: I think dismantling the development tools moduleset is an error. Having a clear message on which are the preferred tools for development is crucial to attract new developers and what should I use? is one of the more frequent questions for new developers approaching gnome. Ciao Paolo On Thu, 2010-10-07 at 13:38 +0200, Vincent Untz wrote: Hi, The release team updated the proposal to reorganize the modulesets. We discussed a first version back in June [1], and there are a few visible changes: - we added a system platform category in the platform, and we now also talk about dbus services there. - we listened to the feedback where people didn't like the fact that inclusion of applications had no barrier to entry at all. We do think the Core Desktop vs Applications separation is good, and we also believe it's important to simplify the process and to be more liberal for simple applications (ie, applications that won't be in the Core Desktop). - we also listened to translators, who have a need for a simple workflow. There is no perfect solution for now, but we propose a way forward. This is obviously an important topic, so please take some time to read the proposal and send feedback. I apologize for this being a bit late; purely my fault. Cheers, Vincent [1] http://mail.gnome.org/archives/desktop-devel-list/2010-June/msg1.html == GNOME Moduleset Reorganization: Platform, Bindings == We identified various issues with our current Platform moduleset: + bindings are not part of it, and feel like second-class citizen. + some libraries that are targetted at the platform are not API/ABI stable yet. While we should still encourage their use instead of their alternatives, we didn't have a clear message for this yet. + many modules that are actually part of our platform just appear as external dependencies. + dbus services were not technically part of our platform, while they do provide API/ABI to developers too. System Platform === The System Platform is the set of libraries or dbus services that are used in GNOME, but are modules belonging to lower parts of the stack. We encourage their use for GNOME applications. This set might change over the years, and API/ABI stability is up to the respective developers. However, we will encourage them to guarantee stability. Candidates for this set include: ConsoleKit, NetworkManager, Xorg, avahi, bluez, cairo, dbus, geoclue, gudev, libxml, pulseaudio, udisks, upower. API/ABI Stable Platfom == The API/ABI Stable Platfom works in the exact same way as the GNOME 2.x moduleset, but it can also include dbus services that guarantee stability of their dbus interfaces. However, to the libraries of the GNOME 2.x moduleset, we also add the stable bindings for GNOME, to make them first-class citizen in our message to developers. Extended Platform = The Extended Platform is a set of libraries or dbus services that do not provide API/ABI stability yet, but that fill holes in our platform and that should end in our platform once they reach stability. We encourage developers to use them instead of alternative solutions. Additionally, bindings that are still in development will also be in the Extended Platform. Candidates for this set include GStreamer, enchant, evolution-data-server, libcanberra, libgda, libnotify, gupnp, poppler, telepathy-glib, tracker, webkitgtk. Candidate bindings include java-gnome. = GNOME Moduleset Reorganization: Desktop, Admin, Dev Tools = The original idea to have Desktop, Admin and Dev Tools modulesets was to separate some applications based on the target user: end-user, system administrator, or developer. It worked okayish, but it turned out that most applications just ended up in Desktop, and it started getting harder and harder to put a limit on what kind of application can live in the Desktop. Moreover, when there are competing applications for a same use case, we could not choose one application without sending a message that the other applications were not as good, and this forced us to stay neutral (the classical banshee vs rhythmbox example). We propose a solution where we keep a core desktop, which is the part of GNOME that everybody uses,
Re: Moduleset Reorganization -- Take two
On Tue, Oct 12, 2010 at 5:59 AM, Vincent Untz vu...@gnome.org wrote: Le jeudi 07 octobre 2010, à 07:32 -0700, Sandy Armstrong a écrit : On Thu, Oct 7, 2010 at 4:38 AM, Vincent Untz vu...@gnome.org wrote: Moreover, we encourage maintainers of applications that are part of the Desktop today and that are not core applications to consider helping with the bootstrap efforts of this application set by moving their applications there. What are the downsides, if any, of moving your application out of Core? Perceived loss of status/importance to GNOME? Any practical differences? The goal is to not have any downside :-) snip satisfying answer Alrighty then, let's do it. Let me know what I need to do to move Tomboy to this new suite and we'll call it a day. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Hi! Anyway for now I'd like to concentrate on a separate point: I think dismantling the development tools moduleset is an error. Having a clear message on which are the preferred tools for development is crucial to attract new developers and what should I use? is one of the more frequent questions for new developers approaching gnome. This is one of the main reasons for the Development Tools Documentation Hackfest happening in december[1]. We hope to be able to provide a solid answer for this what should I use question there. However, I am mixed about the development tools moduleset. Basically we need a lot of improvements in that area and probably it is far more useful to have a central point to start (like a revived developer.gnome.org) that explains and shows the tools than to put them in a moduleset. A moduleset is something pretty technical that is unlikely to get much attention outside of people having to deal with releases/translations. A nice thing that happend at GUADEC though: In some talk I poke somebody hacking because he was using anjuta and his answer was: Yeah, I though everybody was using that :) Regards, Johannes [1] http://live.gnome.org/Hackfests/DevDocTools 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
developer.gnome.org (was: Moduleset Reorganization -- Take two)
Am Dienstag, den 12.10.2010, 18:03 +0200 schrieb Johannes Schmid: However, I am mixed about the development tools moduleset. Basically we need a lot of improvements in that area and probably it is far more useful to have a central point to start (like a revived developer.gnome.org) that explains and shows the tools than to put them in a moduleset. That would require to first kill the rest of content on developer.gnome.org. I've listed the remaining stuff on developer.gnome.org in http://mail.gnome.org/archives/gnome-doc-list/2010-May/msg00063.html The big problems are * how to tell that stuff is outdated (needs developer input as I cannot judge that) * whether it is still useful for anybody to keep it / archive it * in case it's still useful: whether to move it to some archive (live.gnome.org? project websites?) and to create permanent redirects in developer.gnome.org's htaccess to avoid 404s. I'm willing to tackle this but obviously wonder about the best way to proceed. Thoughts? Separately emailing the authors of the content and ask them? andre -- mailto:ak...@gmx.net | failed 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: Moduleset Reorganization -- Take two
On Tue, 2010-10-12 at 15:03 +0200, Vincent Untz wrote: Good point. It's fair to expect projects not using the GNOME development cycle to publish a schedule with freezes. You would allow modules in the module sets that don't follow the GNOME schedule? Then it loses all meaning. Once again, the purpose of the release schedule (of which the module sets are just a part) is to release software. -- 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: Moduleset Reorganization -- Take two
On Tue, Oct 12, 2010 at 1:31 PM, Murray Cumming murr...@murrayc.com wrote: On Tue, 2010-10-12 at 15:03 +0200, Vincent Untz wrote: Good point. It's fair to expect projects not using the GNOME development cycle to publish a schedule with freezes. You would allow modules in the module sets that don't follow the GNOME schedule? Then it loses all meaning. Once again, the purpose of the release schedule (of which the module sets are just a part) is to release software. I agree here. I'm not sure how the i18n and docs teams are supposed to do their jobs if they have to track dozens of different schedules. Maybe those teams should only devote resources to an application on the occasion that a release matches up with the GNOME schedule? This would allow for apps to have more or less frequent releases, but at the same time encourage them to have their releases match up with the GNOME schedule whenever possible. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On Di, 12.10.2010 14:59, Vincent Untz wrote: For example, if Tomboy moves out of Core, then we will still talk about it the way we talk about it today. We would want to keep mentioning cool new features in the release notes, and I guess that should address concerns about the perception. Maybe it's just me, but I'm afraid that the release notes might end up delivering unwanted messages. Say there is videoplayer 1, with new features A,B and C. Then there is videoplayer 2, with new features D and E. Maybe it had features A and B before anyways, but not C. So, if a user is interested in all that cool stuff in the release notes - what's he supposed to use? So what message does this convey about a GNOME release? That it offers a consistant, tightly integrated desktop user experience? Or that it's a loose collection of somewhat related, partly overlapping applications? Holger ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On Tue, Oct 12, 2010 at 2:07 PM, Holger Berndt bern...@gmx.de wrote: On Di, 12.10.2010 14:59, Vincent Untz wrote: For example, if Tomboy moves out of Core, then we will still talk about it the way we talk about it today. We would want to keep mentioning cool new features in the release notes, and I guess that should address concerns about the perception. Maybe it's just me, but I'm afraid that the release notes might end up delivering unwanted messages. Say there is videoplayer 1, with new features A,B and C. Then there is videoplayer 2, with new features D and E. Maybe it had features A and B before anyways, but not C. So, if a user is interested in all that cool stuff in the release notes - what's he supposed to use? So what message does this convey about a GNOME release? That it offers a consistant, tightly integrated desktop user experience? Or that it's a loose collection of somewhat related, partly overlapping applications? Yes, I'm curious how coherent the release notes will be when they list the latest greatest features from Tomboy, and then the slightly different but generally overlapping set offered by Gnote, in the hypothetical situation where both apps were in the app moduleset. That's only the most extreme example, but Banshee/Rhythmbox sends an equally confusing message. I'm really not sure what the answer here is. I don't think that deemphasizing app features in the release notes would help any, as it would make for increasingly boring reading for users (who tend to care more about apps than core stuff). But it's also a problem if we have longer, conflicting, confusing release notes. Splitting out apps makes sense in a lot of ways, but clearly there are a few sticking points that we need to figure out. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On tis, 2010-10-12 at 14:03 -0700, Sandy Armstrong wrote: On Tue, Oct 12, 2010 at 1:31 PM, Murray Cumming murr...@murrayc.com wrote: On Tue, 2010-10-12 at 15:03 +0200, Vincent Untz wrote: Good point. It's fair to expect projects not using the GNOME development cycle to publish a schedule with freezes. You would allow modules in the module sets that don't follow the GNOME schedule? Then it loses all meaning. Once again, the purpose of the release schedule (of which the module sets are just a part) is to release software. I agree here. I'm not sure how the i18n and docs teams are supposed to do their jobs if they have to track dozens of different schedules. Maybe those teams should only devote resources to an application on the occasion that a release matches up with the GNOME schedule? This would allow for apps to have more or less frequent releases, but at the same time encourage them to have their releases match up with the GNOME schedule whenever possible. With every new GNOME release, we would compose the release of the latest stable version of all the applications, right? So when we tell the application developers to pick a release to be part of a stable GNOME and to be mentioned in the release notes and so on, why don't we require that specific version of that application to follow the UI/string freeze for the 3.x.0 version of GNOME, and that the application releases a stable version - either a new stable, or a point release - when tarballs are due, if there are changes such as new translations? Thus, if you want to have a 4 month release schedule, that means you'd pretty much have to release with GNOME once every 18 months, and for the two gnome releases in between you'd just release updated translations for months old stable versions. If you want to have a 12 months release schedule, you'd still have to provide point releases every 6 months. Applications would still have the option to ignore the schedule for GNOME's unstable releases, as well it's bugfix releases. As many distributions are on a GNOME + a few weeks schedule these days, it should be in the application developers' interest to at least do a bug fix release at or around GNOME release time, so it shouldn't be too much of a burden to fulfill. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
First I should say that I think this all look very good. Considering the proposed goals and the previous feedback, I think you have come up with some elegant solutions. Cheers. + we strongly encourage the application developers to follow the GNOME development cycle. If a different development cycle is used, it has to be documented to help contributors. If you remember from the previous discussions, this is a sensitive subject from a translations resource/translation completeness point of view. The objections were that having a large group of applications (I use the term widely), that has a well defined and common release schedule, makes for a easily definable goals and makes it easy to maximize translation performance with limited resources. This objection still stands, strongly encouraging, does not give me a guarantee against untimely string changes and the concomitant loss of work, the way that the current workflow for the desktop module set to a very large degree does. However, if I try to look at this from a broader perspective, I do see some convincing greater good arguments for this decision. So although the objection is still valid, I think the proposed solution is a worthwhile compromise. (Lets just hope that strongly encourage means way more than 75% of the projects will follow, and not, like I may fear, less than 25% :)) I would like to elaborate on one very important thing that you mention, and that is that if a project chooses not to follow the GNOME release schedule, the key is information. So when/(if) this happens it has to be extremely visibly, preferably right there in l10n.org. So I would suggest as a technical detail to your proposal, that it is a _requirement_ for project maintainers of projects that don't follow the GNOME release schedule, to not only document it in their development fora, but also to publish a (tentative) string freeze and release date somewhere in the repository, so that it can be automatically parsed and published on damned lies. With regards to external translation tools I will reply in the new thread Andre has started. Regards Kenneth ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Am Freitag, den 08.10.2010, 09:13 +0200 schrieb Johannes Schmid: So reminder: We need to fix that BEFORE making any moduleset reorganisation! That would require input from translators. FYI I posted http://mail.gnome.org/archives/gnome-i18n/2010-October/msg00038.html (once it gets delivered). andre -- mailto:ak...@gmx.net | failed 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: Moduleset Reorganization -- Take two
Le jeudi 07 octobre 2010 à 13:38 +0200, Vincent Untz a écrit : API/ABI Stable Platfom == The API/ABI Stable Platfom works in the exact same way as the GNOME 2.x moduleset, but it can also include dbus services that guarantee stability of their dbus interfaces. I’m thrilled to finally see guaranteed ABI stability on D-Bus interfaces. This has been one of the major problems we had to deal with upon upgrades. Unlike shared libraries, t is ver The Core Desktop is the set of components that are needed to get a desktop session running and to have it provide core functionalities (display manager, session manager, desktop shell, file manager, settings manager, etc.). Where do you draw the line with some applications that should be part of any desktop, like eog and evince? + we strongly encourage the application developers to follow the GNOME development cycle. If a different development cycle is used, it has to be documented to help contributors. Without that, how do you decide, at the time of the release, which version of the application will go into the release? This is not an innocent question; when something changes (often in an incompatible way) in the extended platform, you need to ensure that all applications work consistently with it. Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling 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: Moduleset Reorganization -- Take two
Le samedi 09 octobre 2010 à 09:25 +0200, Josselin Mouette a écrit : The API/ABI Stable Platfom works in the exact same way as the GNOME 2.x moduleset, but it can also include dbus services that guarantee stability of their dbus interfaces. I’m thrilled to finally see guaranteed ABI stability on D-Bus interfaces. This has been one of the major problems we had to deal with upon upgrades. Unlike shared libraries, t is ver I meant to say: there is no automated versioning system that we can rely on. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling 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: Moduleset Reorganization -- Take two
Hi! Michael Terry m...@mterry.name, Fri, 8 Oct 2010 10:30:14 -0400: On 8 October 2010 03:13, Johannes Schmid j...@jsschmid.de wrote: The best solution IMHO would be to import PO files for all applications, and integrate them into Damned Lies. Else, we're taking the risk of losing consistency, and « moduleset » won't mean anything in the end. I am afraid that the problem is not to import PO files in damned-lies but to commit them from damned-lies to the repositories. And we have to find a solution for this while keeping the current permissions that are specific to git.gnome.org. From a Launchpad perspective, a translation branch can be imported from git into a bzr branch in Launchpad. This would involve zero change from an LP maintainer perspective (currently, there is a bzr branch in LP for translations that gets written to by translators through the web interface; maintainers merge that branch before a release). So the trick then would be having Damned Lies import pot/po files from a bzr trunk. Then GNOME translators can edit them in git like they like. Then LP can import that translation branch with changes. Eh? I think that would be very acceptable to GNOME translators, while keeping the main development at a location of developer's preference. (CC'ing gnome-i18n as this is definitely of interest to the members of that group as well.) Best, Petr Kovar ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Hi! I can't really speak for translators, as I only contributed a few strings in GNOME (but I also translate software in Ubuntu, so I know Launchpad too). But I think we're going to open Pandora's box if we allow applications to be translated using different systems. There will be the « core applications », that are hosted on git.gnome.org and get good quality translations as now, and other peripheral applications that will quite possibly get less attention because tracking their status and learning their translation systems will be a pain. The best solution IMHO would be to import PO files for all applications, and integrate them into Damned Lies. Else, we're taking the risk of losing consistency, and « moduleset » won't mean anything in the end. I am afraid that the problem is not to import PO files in damned-lies but to commit them from damned-lies to the repositories. And we have to find a solution for this while keeping the current permissions that are specific to git.gnome.org. So reminder: We need to fix that BEFORE making any moduleset reorganisation! Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On Fri, Oct 8, 2010 at 3:13 AM, Johannes Schmid j...@jsschmid.de wrote: Hi! So reminder: We need to fix that BEFORE making any moduleset reorganisation! No, we are not going to let moduleset reorganization held hostage in this way. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On Thu, 2010-10-07 at 13:38 +0200, Vincent Untz wrote: Hi, The release team updated the proposal to reorganize the modulesets. We discussed a first version back in June [1], and there are a few visible changes: - we added a system platform category in the platform, and we now also talk about dbus services there. - we listened to the feedback where people didn't like the fact that inclusion of applications had no barrier to entry at all. We do think the Core Desktop vs Applications separation is good, and we also believe it's important to simplify the process and to be more liberal for simple applications (ie, applications that won't be in the Core Desktop). - we also listened to translators, who have a need for a simple workflow. There is no perfect solution for now, but we propose a way forward. This is obviously an important topic, so please take some time to read the proposal and send feedback. I apologize for this being a bit late; purely my fault. Cheers, Vincent [1] http://mail.gnome.org/archives/desktop-devel-list/2010-June/msg1.html == GNOME Moduleset Reorganization: Platform, Bindings == We identified various issues with our current Platform moduleset: + bindings are not part of it, and feel like second-class citizen. + some libraries that are targetted at the platform are not API/ABI stable yet. While we should still encourage their use instead of their alternatives, we didn't have a clear message for this yet. + many modules that are actually part of our platform just appear as external dependencies. + dbus services were not technically part of our platform, while they do provide API/ABI to developers too. System Platform === The System Platform is the set of libraries or dbus services that are used in GNOME, but are modules belonging to lower parts of the stack. We encourage their use for GNOME applications. This set might change over the years, and API/ABI stability is up to the respective developers. However, we will encourage them to guarantee stability. Candidates for this set include: ConsoleKit, NetworkManager, Xorg, avahi, bluez, cairo, dbus, geoclue, gudev, libxml, pulseaudio, udisks, upower. And fprintd (as used in the old gnome-about-me, the new accounts dialogue, and with special gdm support). I'd add geoclue there as well, when it sucks less. snip Extended Platform = snip Candidates for this set include GStreamer, enchant, evolution-data-server, libcanberra, libgda, libnotify, gupnp, poppler, telepathy-glib, tracker, webkitgtk. Candidate bindings include java-gnome. totem-pl-parser (as used by Totem and Rhythmbox) = GNOME Moduleset Reorganization: Desktop, Admin, Dev Tools = The original idea to have Desktop, Admin and Dev Tools modulesets was to separate some applications based on the target user: end-user, system administrator, or developer. It worked okayish, but it turned out that most applications just ended up in Desktop, and it started getting harder and harder to put a limit on what kind of application can live in the Desktop. Moreover, when there are competing applications for a same use case, we could not choose one application without sending a message that the other applications were not as good, and this forced us to stay neutral (the classical banshee vs rhythmbox example). We propose a solution where we keep a core desktop, which is the part of GNOME that everybody uses, and applications, containing the various applications that people use. Note: related to this, it's worth considering a tag-based approach instead of single-category like we did. The categories defined in the xdg menu specification can be used for this, whenever we will have to present applications in a categorized way. Core Desktop The Core Desktop is the set of components that are needed to get a desktop session running and to have it provide core functionalities (display manager, session manager, desktop shell, file manager, settings manager, etc.). I'm guessing this will include system settings type functionality (like the volume control, or Bluetooth). Will that also include things like eog, evince, totem? Applications snip + the application developers do not have to use GNOME resources. Critical resources, like the vcs or the bug tracker, have to be easy to find and documented to help contributors. Additionally, the use of OpenID is encouraged to avoid the need of creating accounts. Pain. What's most interesting in having an application in the GNOME infrastructure is that you can do drive-by fixes. If I use an app, I don't need special
Re: Moduleset Reorganization -- Take two
Hi! On Fri, Oct 8, 2010 at 3:13 AM, Johannes Schmid j...@jsschmid.de wrote: Hi! So reminder: We need to fix that BEFORE making any moduleset reorganisation! No, we are not going to let moduleset reorganization held hostage in this way. Do you mean we will release GNOME 3.0 without working module translations? Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On 8 October 2010 03:13, Johannes Schmid j...@jsschmid.de wrote: The best solution IMHO would be to import PO files for all applications, and integrate them into Damned Lies. Else, we're taking the risk of losing consistency, and « moduleset » won't mean anything in the end. I am afraid that the problem is not to import PO files in damned-lies but to commit them from damned-lies to the repositories. And we have to find a solution for this while keeping the current permissions that are specific to git.gnome.org. From a Launchpad perspective, a translation branch can be imported from git into a bzr branch in Launchpad. This would involve zero change from an LP maintainer perspective (currently, there is a bzr branch in LP for translations that gets written to by translators through the web interface; maintainers merge that branch before a release). So the trick then would be having Damned Lies import pot/po files from a bzr trunk. Then GNOME translators can edit them in git like they like. Then LP can import that translation branch with changes. Eh? -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
fr., 08.10.2010 kl. 13.35 +0200, skrev Johannes Schmid: Hi! On Fri, Oct 8, 2010 at 3:13 AM, Johannes Schmid j...@jsschmid.de wrote: Hi! So reminder: We need to fix that BEFORE making any moduleset reorganisation! No, we are not going to let moduleset reorganization held hostage in this way. Do you mean we will release GNOME 3.0 without working module translations? Probably easier to just not accept applications into GNOME 3.0 before this is solved. Then we can reorganize the existing moduleset without worrying about this issue in that respect. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Moduleset Reorganization -- Take two
Hi, The release team updated the proposal to reorganize the modulesets. We discussed a first version back in June [1], and there are a few visible changes: - we added a system platform category in the platform, and we now also talk about dbus services there. - we listened to the feedback where people didn't like the fact that inclusion of applications had no barrier to entry at all. We do think the Core Desktop vs Applications separation is good, and we also believe it's important to simplify the process and to be more liberal for simple applications (ie, applications that won't be in the Core Desktop). - we also listened to translators, who have a need for a simple workflow. There is no perfect solution for now, but we propose a way forward. This is obviously an important topic, so please take some time to read the proposal and send feedback. I apologize for this being a bit late; purely my fault. Cheers, Vincent [1] http://mail.gnome.org/archives/desktop-devel-list/2010-June/msg1.html == GNOME Moduleset Reorganization: Platform, Bindings == We identified various issues with our current Platform moduleset: + bindings are not part of it, and feel like second-class citizen. + some libraries that are targetted at the platform are not API/ABI stable yet. While we should still encourage their use instead of their alternatives, we didn't have a clear message for this yet. + many modules that are actually part of our platform just appear as external dependencies. + dbus services were not technically part of our platform, while they do provide API/ABI to developers too. System Platform === The System Platform is the set of libraries or dbus services that are used in GNOME, but are modules belonging to lower parts of the stack. We encourage their use for GNOME applications. This set might change over the years, and API/ABI stability is up to the respective developers. However, we will encourage them to guarantee stability. Candidates for this set include: ConsoleKit, NetworkManager, Xorg, avahi, bluez, cairo, dbus, geoclue, gudev, libxml, pulseaudio, udisks, upower. API/ABI Stable Platfom == The API/ABI Stable Platfom works in the exact same way as the GNOME 2.x moduleset, but it can also include dbus services that guarantee stability of their dbus interfaces. However, to the libraries of the GNOME 2.x moduleset, we also add the stable bindings for GNOME, to make them first-class citizen in our message to developers. Extended Platform = The Extended Platform is a set of libraries or dbus services that do not provide API/ABI stability yet, but that fill holes in our platform and that should end in our platform once they reach stability. We encourage developers to use them instead of alternative solutions. Additionally, bindings that are still in development will also be in the Extended Platform. Candidates for this set include GStreamer, enchant, evolution-data-server, libcanberra, libgda, libnotify, gupnp, poppler, telepathy-glib, tracker, webkitgtk. Candidate bindings include java-gnome. = GNOME Moduleset Reorganization: Desktop, Admin, Dev Tools = The original idea to have Desktop, Admin and Dev Tools modulesets was to separate some applications based on the target user: end-user, system administrator, or developer. It worked okayish, but it turned out that most applications just ended up in Desktop, and it started getting harder and harder to put a limit on what kind of application can live in the Desktop. Moreover, when there are competing applications for a same use case, we could not choose one application without sending a message that the other applications were not as good, and this forced us to stay neutral (the classical banshee vs rhythmbox example). We propose a solution where we keep a core desktop, which is the part of GNOME that everybody uses, and applications, containing the various applications that people use. Note: related to this, it's worth considering a tag-based approach instead of single-category like we did. The categories defined in the xdg menu specification can be used for this, whenever we will have to present applications in a categorized way. Core Desktop The Core Desktop is the set of components that are needed to get a desktop session running and to have it provide core functionalities (display manager, session manager, desktop shell, file manager, settings manager, etc.). This Core Desktop will be a moduleset, in the same way we did the Desktop moduleset for GNOME 2. It will have the same rules, including the requirement to use GNOME resources. Initially, for GNOME 3.0, it will be populated with the modules from the GNOME 2.x
Re: Moduleset Reorganization -- Take two
Hi! Initially, for GNOME 3.0, it will be populated with the modules from the GNOME 2.x Desktop moduleset. However, we would like to slowly migrate some modules to the Applications moduleset. I guess everything related to accessibility will stay in Desktop, right? It's worth mentioning that we understand that a unique workflow is important in general, and especially for translators. Using l10n.gnome.org is nice, and it's probably worth investigating some way to have l10n.gnome.org interact with transifex.org, as well as registering the GNOME translation teams in transifex.org, to support applications hosted outside of the GNOME infrastructure. This way, translators would still be able to simply look at l10n.gnome.org. What about Launchpad? I think if we want to integrate which other hosting possibilities we definitely need a working i18n-solution with Transiflex and Launchpad before accepting applications from there. Probably something the sysadmin-team and the i18n-team should focus on in this cycle. But that might also involve a political decision with existing Launchpad teams to accept that certain projects are translated using the GNOME infrastructure. We want to bootstrap applications with the ones that were proposed for inclusion for 3.0: deja-dup, pdfmod, simple-scan. In addition to those, we want to invite applications that have been historically close to our project (banshee, f-spot, rhythmbox), as well as various popular applications. I see no mention of the applications currently in Admin or Development Tools section. I guess those should be moved to Applications initially. Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Hi! Core Desktop The Core Desktop is the set of components that are needed to get a desktop session running and to have it provide core functionalities (display manager, session manager, desktop shell, file manager, settings manager, etc.). IMHO this should include the following: evince, eog, yelp, file-roller, seahorse and totem as those are integral part of what I see as the Desktop. (Those fit in the open a file vs. start an application metapher). (sorry, for replying twice...) Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On 7 October 2010 07:57, Johannes Schmid j...@jsschmid.de wrote: What about Launchpad? I think if we want to integrate which other hosting possibilities we definitely need a working i18n-solution with Transiflex and Launchpad before accepting applications from there. Probably something the sysadmin-team and the i18n-team should focus on in this cycle. For Launchpad applications (such as mine, Deja Dup), I proposed three ways we could smooth the way for GNOME/LP interaction last time this came up: 1) Having an approved GNOME coding team (~gnome-team?) that the maintainer sets to own the trunk. This way, documenters and GNOME-approved coders can directly commit. It would be best if being added to that team was automatic. Then have some documentation that says, for this app, here is the trunk. 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 Translations, they wouldn't need direct access to trunk, but it wouldn't hurt if they chose to edit directly instead of the web interface. Existing translation teams should be encouraged to join that team (or automatically added), as it seems a little sparse right now: https://translations.launchpad.net/+groups/gnome-translation-project 3) For the documentation team, a similar situation. Again, this would need some documentation 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: Moduleset Reorganization -- Take two
On Thu, Oct 7, 2010 at 4:38 AM, Vincent Untz vu...@gnome.org wrote: Moreover, we encourage maintainers of applications that are part of the Desktop today and that are not core applications to consider helping with the bootstrap efforts of this application set by moving their applications there. What are the downsides, if any, of moving your application out of Core? Perceived loss of status/importance to GNOME? Any practical differences? Tomboy seems like a pretty obvious choice to move to Applications, but I don't want to end up regretting later if there's something I'm missing. ;-) Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On Thu, 2010-10-07 at 13:38 +0200, Vincent Untz wrote: + feedback will not be centered around the goal of the application, but about its technical merits: - use of GNOME technologies - integration with the Core Desktop - usability and respect of the HIG - existence of localization issues or not - status of documentation - accessibility support But you will still require these modules to actually follow the release schedule, right, such as feature freezes, string freezes, UI freezes, hard-code freeze, etc? The point of the release sets (and the release team) is still to release software, I hope. -- 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: Moduleset Reorganization -- Take two
From: Johannes Schmid j...@jsschmid.de Hi! Initially, for GNOME 3.0, it will be populated with the modules from the GNOME 2.x Desktop moduleset. However, we would like to slowly migrate some modules to the Applications moduleset. I guess everything related to accessibility will stay in Desktop, right? This is a good question, and I have some doubts, probably because in some cases there are a thin line between Core Desktop and Applications I guess that in this proposal modules like at-spi2-atk or pyatspi2 will be obviously in the Core Desktop, as they are fundamental to the a11y support. But if we move forward toward the line we find Orca: * It is a application = should stay in Applications? * But it one of the basic accessibility modules = should stay in Core Desktop? And if we keep moving forward we find Accerciser: * It is a application = should stay in Applications? * But it one of the basic accessibility modules = should stay in Core Desktop? * Well, yes, basic module, but for developers = additional point to move it to Applications? Probably it is because I don't fully understand the proposal. Also if anyone make the classification of those applications, and the reasons for that, could be a way to understand it. BR === API (apinhe...@igalia.com) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On Thu, Oct 7, 2010 at 11:08 AM, Piñeiro apinhe...@igalia.com wrote: I guess everything related to accessibility will stay in Desktop, right? This is a good question, and I have some doubts, probably because in some cases there are a thin line between Core Desktop and Applications The main thrust of the proposal is to make this line more clear. We believe that we can make both our core desktop and our applications better by having a clear understanding of what is part of the core and what is an application. As for the concrete question, I agree that a11y needs to stay a part of the core desktop shell. For individual components, like orca, I think we need to move in a direction where they are less individual add-on applications, but instead integrated right into the shell. You can already see that happening with the magnifier. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Hi, On Thu, Oct 7, 2010 at 7:38 AM, Vincent Untz vu...@gnome.org wrote: Candidates for this set include: ConsoleKit, NetworkManager, Xorg, avahi, bluez, cairo, dbus, geoclue, gudev, libxml, pulseaudio, udisks, upower. This should include polkit since a) udisks and other services will not work without it; and b) other parts of our stack (such as dconf) really wants to rely on it too. Thanks, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On Thu, Oct 7, 2010 at 06:38, Vincent Untz vu...@gnome.org wrote: Moreover, we encourage maintainers of applications that are part of the Desktop today and that are not core applications to consider helping with the bootstrap efforts of this application set by moving their applications there. I would like to move GNOME Games to the Application set so what action do I need to take to make that happen? Also, I want to send a strong encouragement to apply for inclusion in Applications to people whom have proposed games for GNOME Games in the past that have been rejected because the game was in a language which was not in the core competency of existing GNOME Games maintainers and contributors (especially some of the Java, Ruby and C++ proposals which we have seen). I think a small tweak to GNOME Game's name may help too: GNOME Games Collection (thus avoiding implying they are the only GNOME Games). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
From: Matthias Clasen matthias.cla...@gmail.com On Thu, Oct 7, 2010 at 11:08 AM, Piñeiro apinhe...@igalia.com wrote: I guess everything related to accessibility will stay in Desktop, right? This is a good question, and I have some doubts, probably because in some cases there are a thin line between Core Desktop and Applications The main thrust of the proposal is to make this line more clear. Ok. We believe that we can make both our core desktop and our applications better by having a clear understanding of what is part of the core and what is an application. Ok. As for the concrete question, I agree that a11y needs to stay a part of the core desktop shell. For individual components, like orca, I think we need to move in a direction where they are less individual add-on applications, but instead integrated right into the shell. You can already see that happening with the magnifier. I'm not sure if I'm understanding this paragraph. Taking into account that this happening with the magnifier is that right now gnome-shell has a built-in magnification feature (no plugin, all code inside, mostly JavaScript AFAIK). Are you proposing to add at-spi2 compliant screen reader with braille support as a gnome-shell feature? BR === API (apinhe...@igalia.com) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Le jeudi 07 octobre 2010 à 08:30 -0400, Michael Terry a écrit : On 7 October 2010 07:57, Johannes Schmid j...@jsschmid.de wrote: What about Launchpad? I think if we want to integrate which other hosting possibilities we definitely need a working i18n-solution with Transiflex and Launchpad before accepting applications from there. Probably something the sysadmin-team and the i18n-team should focus on in this cycle. For Launchpad applications (such as mine, Deja Dup), I proposed three ways we could smooth the way for GNOME/LP interaction last time this came up: 1) Having an approved GNOME coding team (~gnome-team?) that the maintainer sets to own the trunk. This way, documenters and GNOME-approved coders can directly commit. It would be best if being added to that team was automatic. Then have some documentation that says, for this app, here is the trunk. 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 Translations, they wouldn't need direct access to trunk, but it wouldn't hurt if they chose to edit directly instead of the web interface. Existing translation teams should be encouraged to join that team (or automatically added), as it seems a little sparse right now: https://translations.launchpad.net/+groups/gnome-translation-project 3) For the documentation team, a similar situation. Again, this would need some documentation that says, 'for this app, edit docs in this trunk'. Then they could directly commit. I can't really speak for translators, as I only contributed a few strings in GNOME (but I also translate software in Ubuntu, so I know Launchpad too). But I think we're going to open Pandora's box if we allow applications to be translated using different systems. There will be the « core applications », that are hosted on git.gnome.org and get good quality translations as now, and other peripheral applications that will quite possibly get less attention because tracking their status and learning their translation systems will be a pain. The best solution IMHO would be to import PO files for all applications, and integrate them into Damned Lies. Else, we're taking the risk of losing consistency, and « moduleset » won't mean anything in the end. Of course, I'd like to hear what « real » translators think of this change. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
