GNOME 3.11.91 release
Hi, the second beta release of the GNOME 3.11 development cycle is finally here! With this release we are officially now in "The String Freeze" [1] (that stacks with all the current freezes): - String Freeze: no string changes may be made without confirmation from the l10n team (gnome-i18n@) and notification to both the release team and the GDP (gnome-doc-list@). More details about changes and news for this beta are available here: core: http://download.gnome.org/core/3.11/3.11.91/NEWS apps: http://download.gnome.org/apps/3.11/3.11.91/NEWS The GNOME 3.11.91 release itself is available here: core sources: http://download.gnome.org/core/3.11/3.11.91/ apps sources: http://download.gnome.org/apps/3.11/3.11.91/ JHBuild modulesets to compile GNOME 3.11.91 by hand are available here http://download.gnome.org/teams/releng/3.11.91/ Check the Smoketesting documentation [2] for instructions about how to compile and test GNOME with these modulesets. WARNING! WARNING! WARNING! -- This release is a snapshot of development code. Although it is buildable and usable, it is primarily intended for testing and hacking purposes. GNOME uses odd minor version numbers to indicate development status. For more information about 3.12, the full schedule, the official module lists and the proposed module lists, please see our colourful 3.12 page: http://www.gnome.org/start/unstable For a quick overview of the GNOME schedule, please see: http://live.gnome.org/Schedule [1] https://live.gnome.org/ReleasePlanning/Freezes [2] https://live.gnome.org/Smoketesting -- Javier Jardón Cabezas GNOME Release Team ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Coordination for developer documentations
On Tue, Mar 04, 2014 at 07:05:30PM +0100, Frederic Peters wrote: > I was mostly concerned by our technical infrastructure for developer > documentation, but that itself has of course been driven by the > content we produced (or wanted to produce), so I don't think they can > really be separated. For the content, what is really needed in my opinion is a good and recent book on GLib and GTK+. GTK+ 3 is maybe too unstable for writing a book, but GLib (including GObject and GIO) is stable enough. It could be a simple update of an existing book, such as The Official GNOME 2 Developer's Guide. The book should also be freely available on the web, with a free license (Creative Commons for example). If the book focus on the C language, it makes sense to write also chapters on how to write good libraries, how to design good APIs with GObject, what are the best practices, etc. This is something less well documented. And this can also be beneficial for internal code in applications, not just libraries. Another thing, I see sometimes on IRC some questions about how to use a certain API, or questions on some details not documented. Ideally when such a question is answered, the API documentation should be improved at the same time, so it benefits other people. I don't know if such small improvements are often done, but if everybody takes the time to write patches for the documentation when a problem is encountered, the documentation will get better over the time. Best regards, Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Status of privacy features in GNOME
Hi. On Thu, Mar 06, 2014 at 04:41:32PM +0100, Stef Walter wrote: > Andreas or Tobias would know definitively ... but I don't think that any > implementation has been undertaken by GNOME as of yet. that is correct. Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Status of privacy features in GNOME
Andreas or Tobias would know definitively ... but I don't think that any implementation has been undertaken by GNOME as of yet. Stef On 06.03.2014 16:09, Oliver Propst wrote: > Hi, > I'm active in the GNOME engagement team and are currently working on a > article about the 2012-2013 privacy campaign for the GNOME annual > report. To complete the article I need know what privacy features have > been implemented as a result of the campaign. Information about this > are very much appreciated, thanks. > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Coordination for developer documentations
On 6 March 2014 10:07, Christoph Reiter wrote: > (responding to the wrong mail since I just subscribed and don't bother > modifying mail headers..) > > Since it wasn't mentioned so far; outside of gnome.org, on the Python > side of things, there exists the GTK+ 3 tutorial [0] maintained by > Sebastian Pölsterl (accepts pull requests, but isn't actively working > on it [1]) and the gi api reference [2], which I actively maintain. I have been using these recently and am very keen to see them on developer.gnome.org. There is a developer experience hackfest[3] coming up at the end of April which would be a perfect time to make that happen, is there any chance that you could make it? > There doesn't seem to be a dedicated IRC channel, so I'm idling in > #docs-devel now At the moment, we use #docs for everything. > [0] http://python-gtk-3-tutorial.readthedocs.org > [1] http://github.com/sebp/PyGObject-Tutorial/issues/35 > [2] http://lazka.github.io/pgi-docs/api/Gtk_3.0/classes/Container.html [3] https://wiki.gnome.org/Hackfests/DeveloperExperience2014 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Coordination for developer documentations
(responding to the wrong mail since I just subscribed and don't bother modifying mail headers..) Since it wasn't mentioned so far; outside of gnome.org, on the Python side of things, there exists the GTK+ 3 tutorial [0] maintained by Sebastian Pölsterl (accepts pull requests, but isn't actively working on it [1]) and the gi api reference [2], which I actively maintain. There doesn't seem to be a dedicated IRC channel, so I'm idling in #docs-devel now [0] http://python-gtk-3-tutorial.readthedocs.org [1] http://github.com/sebp/PyGObject-Tutorial/issues/35 [2] http://lazka.github.io/pgi-docs/api/Gtk_3.0/classes/Container.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translating GObject properties names and descriptions
On Mon, Feb 17, 2014 at 07:20:19PM +, Emmanuele Bassi wrote: > this blog from Stack Overflow about the introduction of their > localised version in Portuguese gives a nice introduction to the > issue, and some very interesting discussion points: > > http://blog.stackoverflow.com/2014/02/cant-we-all-be-reasonable-and-speak-english/ > > in short: increasing the localization of documentation for non-English > speaking developers increases the visibility of those developers to > the overall community, and that is a good thing. For Stack Overflow it was more for writing. Here for GObject properties it is only for reading purposes. > from a library maintainer perspective, I'd probably remove the > localization around the "blurb" field — or even set it to NULL, given > that it's pretty much pointless. I'd still keep the localization of > the nick: a GUI half in english and half in the user's language would > look pretty poor to me. Sounds like a good plan. Thank you for your response. Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
