Re: Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)
Bastien Nocera wrote: > I haven't looked at library-web because I have a whole bunch of work > that I'd need to do with it, but not the bandwidth... I pushed an untested minimal change. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How to manually update https://help.gnome.org/users/$PROJECT?
Milan Crha wrote: > I'm not sure whether this is the right list for this, thus I'm sorry if > it's not. Feel free to redirect me to the right place. gnome-doc-list@ would be the right place, especially as there are plans to redo help.gnome.org. (ditto for developer.gnome.org). > I'd like to ask: how do I manually update content of > https://help.gnome.org/users/$PROJECT , please? > > As (I guess) the [1] is no near to be fixed/implemented (even though > basically whole GNOME is affected, due to released tarballs not > containing needed files), I'd like to update it manually, if it's fwiw if someone familiar with Python wants to look at it, this comment points to the place: https://gitlab.gnome.org/Infrastructure/library-web/issues/50#note_330963 Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)
Bastien Nocera wrote: > - How? > > It is possible to rename the "master" branch in git. It's also possible > to add a "link" of sorts so that software that specifically references > "master" can be made to work with the new name[5]. I checked and there is an hardcoded reference (git) master (branch) in library-web; while other GNOME changes did destroy much of library-web (meson without alternative way to get gtk-doc HTML files), it would still be nice to have the compatibility link (or for someone to step up and adapt library-web). And looking at it now, jhbuild, too, has references to the branch. cheers, Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Let's kill gnome-common!
Milan Crha wrote: > On Tue, 2018-02-13 at 11:19 +, Emmanuele Bassi wrote: > > Work is in progress to let maintainers upload tarballs with the > > generate API reference for developer.gnome.org > > Hi, > okay, how is that supposed to work in general? As Meson builds out of > the source tree, is that "work in progress" meant to be Meson specific? Developer.gnome.org still looks for "markers" in source tarballs (like include gtk-doc.make in Makefile.am) and use those to extract the documentation module name (ex: for gtk+ it would extract three doc modules, gtk4, gdk4, gsk4). What's new and in progress is the possibility to map those modules to external documentation tarballs that will contain the generated HTML files. Some parts of the process are in place already, from manually generated documentation tarballs for GTK+, published at: https://download.gnome.org/docs/gtk+/3.93/ we can now create https://developer.gnome.org/gtk4/3.93/ (this is very fresh, literally two days ago) Now no maintainer would want the burden to generate those additional tarballs and they should be automatically created and published by a CI system (gnome continuous or buildstream or whatever). Wrt evolution developer.gnome.org still lacks the code to find the gtk-doc markers in CMakeLits.txt files. (some experimental code was added for meson as used in GTK+) Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Let's kill gnome-common!
Emmanuele Bassi wrote: > > I do not want to steal the thread, but when talking about ports to > > Meson, would it make sense to finally fix the infrastructure to work > > with other than automake files too [1]? It's when generating the > > content for developer.|help.gnome.org. Considering that plenty of > > projects already use Meson, either exclusively or as an alternative for > > autotools scripts, then it would be a good idea, from my point of view. > > I'd help myself there, but I do no speak pythonish. I guess someone > > with the knowledge would have that fixed relatively quickly. > > Work is in progress to let maintainers upload tarballs with the > generate API reference for developer.gnome.org; I assume > help.gnome.org would follow the same pattern — but of course we only > have one Frederic, so help is indeed welcome. Actually help.gnome.org is different and easier as the mallard files can be converted to HTML without a full build environment (contrary to gtk-doc); a plan is laid out in bugzilla (#785522) and should be quite simple for anybody with some Python experience: https://git.gnome.org/browse/library-web/tree/src/lgo.py#n700 should be updated to detect other cases, like looking for "set(HELPID" in CMakeLists.txt files, or help_files in meson.build. Then https://git.gnome.org/browse/library-web/tree/src/modtypes/mallard.py#n240 should be changed to get the list of mallard files from those CMakeLists.txt/meson.build files. (alternatively it could just take pages and figures and list of languages looking at the filesystem but then it may fail with pages/languages that are present in git but not supposed to be used). Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: developer.gnome.org and meson
mcatanz...@gnome.org wrote: > developer.gnome.org is going to have some problems because for meson modules > 'ninja dist' does not include generated gtk-doc files in the tarball. At > least one maintainer is working around this by manually generating tarballs > with gtk-doc included instead of using 'ninja dist'. I don't recommend doing > that since that's equivalent to skipping distcheck. It's better to use > meson's dist target. developer.gnome.org is just going to have to learn to > build docs itself. But that often requires a full build environment, which is the reason it doesn't do that. Continuous or whatever CI system should include a step publishing built documentation files, it will then be "easy" for developer.gnome.org to use those. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME 3.21.90 beta tarballs
Hello all, This is still GUADEC but we'd really like to have 3.21.90 tarballs this week, the earlier the better, especially since a notable serie of modules didn't get 3.21.x releases yet. Thanks, Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Keep shipping also generated gtk-doc html/ folder?
Milan Crha wrote: > On Thu, 2016-06-23 at 09:55 +0100, Philip Withnall wrote: > > If I remember correctly, it’s so that the tarballs can be unpacked to > > give documentation on developer.gnome.org without having to build > > anything. Actually gtk-doc did ship the generated files in the tarballs before developer.gnome.org existed, so when I did that part I reused the files that already existed. > I know there had been quite much buzz about the infrastructure > recently, I hope they won't dislike me, but maybe it would worth to > reconsider this and do build the devel-doc for the developer.gnome.org > site (easier to say, than to do, but maybe it could be extracted from > the Continuous builds?). developer.gnome.org can certainly be changed to grab generated HTML files from any place that would have them. > Also, it seem to me that it's the gtk-doc adding to the tarball that > folder and couple files, thus the place to focus any changes on might > be gtk-doc itself. Also there has been several efforts to build on gobject-introspection and expand the documentation to more languages, Mathieu Duponchelle is working on this; if there's interest we can certainly organize a session on API docs during the GUADEC. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME 3.19.2 released
Hi! The second snapshot of GNOME 3.19 is now available, it incorporates updates from 3.18.2 as well as quite a serie of edgier modules. To compile GNOME 3.19.2, you can use the jhbuild [1] modulesets [2] (which use the exact tarball versions from the official release). [1] https://developer.gnome.org/jhbuild/ [2] https://download.gnome.org/teams/releng/3.19.2/ The release notes that describe the changes between 3.18.1 and 3.19.2 are available. Go read them to learn what's new in this release: core - https://download.gnome.org/core/3.19/3.19.2/NEWS apps - https://download.gnome.org/apps/3.19/3.19.2/NEWS The GNOME 3.19.2 release is available here: core sources - https://download.gnome.org/core/3.19/3.19.2 apps sources - https://download.gnome.org/apps/3.19/3.19.2 WARNING! WARNING! WARNING! -- This release is a snapshot of early 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.19, the full schedule, the official module lists and the proposed module lists, please see: http://www.gnome.org/start/unstable For a quick overview of the GNOME schedule, please see: http://live.gnome.org/Schedule Cheers, Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainers, please read this. [Re: GNOME 3.19.2 unstable tarballs due]
Philip Withnall wrote: > > This was mostly done manually (at least as far I am concerned), but > > here is an experiment, > > https://people.gnome.org/~fpeters/health/wanted-releases.html > > > > And the red modules are first targets. > > > > (this has been generated from my local clones, updated a few hours > > ago, if it's something we want to pursue it would be quite nice to > > have this automated and running on GNOME infrastructure) (the disk > > requirements exclude openshift). > > Nice! If it's not much effort to get this running on GNOME > infrastructure, I think it would be useful, and have it linked from the > release reminder e-mails. Actually I already had https://bugzilla.gnome.org/show_bug.cgi?id=743833 (yeah for bugzilla suggesting duplicates), I added a comment. > What do the x/y numbers mean? Numbers are numbers of commits since last tag, first number omits the translation commits. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainers, please read this. [Re: GNOME 3.19.2 unstable tarballs due]
Hi, Philip Withnall wrote: > On Wed, 2015-11-25 at 11:07 +0100, Frederic Peters wrote: > > I'm a bit surprised by 1) but we could certainly automatically > > produce > > a list of maintainers / modules/ time/commits since last release, if > > that could be useful. > > I think 1) would be useful because I have a load of modules which I am > not sure if they need to follow the main GNOME release schedule. I had > a nagging fear they should, but then nobody poked me about doing a > release, so I forgot to check up further. As a result, a lot of my > modules haven’t had releases following the schedule. (Sorry if I have > been a total pain because of this.) > > Would such a list be useful for the release team, as a way of tracking > who needs nagging? If so, then I hope producing it should not be too > much of a drain on your time — if it is a drain, then you probably > shouldn’t do it. This was mostly done manually (at least as far I am concerned), but here is an experiment, https://people.gnome.org/~fpeters/health/wanted-releases.html And the red modules are first targets. (this has been generated from my local clones, updated a few hours ago, if it's something we want to pursue it would be quite nice to have this automated and running on GNOME infrastructure) (the disk requirements exclude openshift). Fred [code at https://git.gnome.org/browse/releng/tree/tools/health/] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainers, please read this. [Re: GNOME 3.19.2 unstable tarballs due]
Bastien Nocera wrote: > > It's been some months we have those reminder emails sent to > > devel-announce-list. Maintainers, make sure you are subscribed. > > > > Maintainers (bis), please do try to respect the Monday 23:59 UTC > > deadline, it's really not fun to chase maintainers for days during > > release weeks. If you know you will be late, tell us, either by > > email > > at release-t...@gnome.org or simply by pinging us on #release-team. > > I'd rather somebody helped me 1) know which of my modules need > releasing 2) do releases. We can of course assist in producing tarballs, just ping us. I'm a bit surprised by 1) but we could certainly automatically produce a list of maintainers / modules/ time/commits since last release, if that could be useful. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainers, please read this. [Re: GNOME 3.19.2 unstable tarballs due]
Shaun McCance wrote: > Question: If I don't intend to make a release because there haven't been > any changes, do you want me to send an email saying so? Nope, that's already something we check before chasing people :) And while it's important to get stable releases out when the only changes are translation updates it is ok to "ignore" them for (early) development releases. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Maintainers, please read this. [Re: GNOME 3.19.2 unstable tarballs due]
Hi! > Tarballs are due on 2015-11-23 before 23:59 UTC for the GNOME 3.19.2 > unstable release, which will be delivered on Wednesday. Modules which > were proposed for inclusion should try to follow the unstable schedule > so everyone can test them. Please make sure that your tarballs will > be uploaded before Monday 23:59 UTC: tarballs uploaded later than that > will probably be too late to get in 3.19.2. If you are not able to > make a tarball before this deadline or if you think you'll be late, > please send a mail to the release team and we'll find someone to roll > the tarball for you! It's been some months we have those reminder emails sent to devel-announce-list. Maintainers, make sure you are subscribed. Maintainers (bis), please do try to respect the Monday 23:59 UTC deadline, it's really not fun to chase maintainers for days during release weeks. If you know you will be late, tell us, either by email at release-t...@gnome.org or simply by pinging us on #release-team. Thanks for your attention, Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME 3.17.92 Release Candidate
Hello all, Here we are, this is the end of this development cycle and here comes a release candidate for you to download, build, and test. Enjoy it as fast as you can, the final release is scheduled next Wednesday. To compile GNOME 3.17.92, you can use the jhbuild modulesets published by the release team (which use the exact tarball versions from the official release). https://developer.gnome.org/jhbuild/ https://download.gnome.org/teams/releng/3.17.92/ We remind you we are string frozen, no string changes may be made without confirmation from the l10n team (gnome-i18n@) and notification to both the release team and the GNOME Documentation Project (gnome-doc-list@). Hard code freeze is also in place, no source code changes can be made without approval from the release-team. Translation and documentation can continue. More details about changes and news for this beta are available here: core: https://download.gnome.org/core/3.17/3.17.92/NEWS apps: https://download.gnome.org/apps/3.17/3.17.92/NEWS The GNOME 3.17.92 release itself is available here: core sources: https://download.gnome.org/core/3.17/3.17.92/ apps sources: https://download.gnome.org/apps/3.17/3.17.92/ 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.17, the full schedule, the official module lists and the proposed module lists, please see our colorful 3.17 page: https://www.gnome.org/start/unstable For a quick overview of the GNOME schedule, please see: https://wiki.gnome.org/Schedule Enjoy, Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How do you hack on GNOME? How can we do better?
Michael Catanzaro wrote: 3) Hacking on session level components (gnome-session, gnome-shell, gnome-settings-daemon), and the libraries they use (gnome-desktop, clutter) [...] Do you log into a jhbuild session? as yourself? as a test user? I used to do 3 on rare occasions, but stopped doing that because I no longer remember how I ever managed to run a GNOME session under jhbuild in the past. There used to be instructions on the wiki, but they got deleted at some point because they became outdated. The problems I wanted to fix were never so urgent as to convince me to impel me to figure it out on my own. Pretty sure new contributors have no chance here. Instructions are still available in the jhbuild documentation itself, https://developer.gnome.org/jhbuild/stable/jhbuild-and-gnome.html.en#running-gnome There may be errors and parts could be simplified (GDK_USE_XFT...) but if you're up for it I'd be happy to spend some time with you, during GUADEC?, to get them working on your laptop, then updated online. (survey answer: I run such a jhbuild session and I mostly use jhbuild make in the module I'm working on) Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME 3.17.3 released
Hey all, The development of the next GNOME release, 3.17, is going on and a new snapshot, 3.17.3, is now available. Give it a shot! Some of us will gather in San Francisco next week for the West Coast Summit 2015, and a month later we will all gather for GUADEC in Gothenburg, Sweden (no relation whatsoever with a conspiracy that doesn't even exist). To compile GNOME 3.17.3, you can use the jhbuild[1] modulesets[2] (which use the exact tarball versions from the official release). [1] https://developer.gnome.org/jhbuild/ [2] https://download.gnome.org/teams/releng/3.17.3/ The release notes that describe the changes between 3.17.2 and 3.17.3 are available. Go read them to learn what's new in this release: core - http://download.gnome.org/core/3.17/3.17.3/NEWS apps - http://download.gnome.org/apps/3.17/3.17.3/NEWS The GNOME 3.17.3 release is available here: core sources - http://download.gnome.org/core/3.17/3.17.3 apps sources - http://download.gnome.org/apps/3.17/3.17.3 WARNING! WARNING! WARNING! -- This release is a snapshot of early 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.17, the full schedule, the official module lists and the proposed module lists, please see our 3.17 page: http://www.gnome.org/start/unstable For a quick overview of the GNOME schedule, please see: http://live.gnome.org/Schedule Cheers, Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Software and fwupd
Hi Richard Richard Hughes wrote: I've just merged a patch to gnome-software which adds an optional (but default enabled) dependency on fwupd[1]. The fwupd project just provides a DBus interface for applying low-level firmware to various types of devices. I don't know if this makes sense for the continuous integration server. I don't know if it makes sense to enable by default. Installing firmware on more devices would be awesome (and make them more secure) but it is Yet Another Dep. Comments welcome, If it stays enabled by default it would have to be added to jhbuild (or the moduleset changed to disable it forcefully, but that's not nice), and this would work as long as fwupdate is installed system-wide, right? Release-team-hat-on, in time of releases it would help to have tarballs created with 'make dist(check)' (I think github allows this, but if that was not the case they could certainly be pushed onto the GNOME ftp server). Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
TARBALLS DUE: 3.16.1
Hi! You've all seen the automated mail posted to devel-announce-list@, here's another one to remind you that tarballs for 3.16.1 are due today. Thanks! Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.15.92 Release Candidate
Sriram Ramkrishna wrote: On Wed, Mar 18, 2015 at 12:46 PM, Frederic Peters fpet...@gnome.org wrote: Hello all, We have now reached the end of the development cycle and here comes a release candidate for you to download, build, and test. Enjoy it as fast as you can, the final release is scheduled next Wednesday. To compile GNOME 3.15.92, you can use the jhbuild modulesets published by the release team (which use the exact tarball versions from the official release). https://developer.gnome.org/jhbuild/ There doesn't seem to be a link for 3.15 or 3.16 here? The first link is about jhbuild, there's a second link with the modulesets: https://download.gnome.org/teams/releng/3.15.92/ Still, about the documentation link, I had plans to roll a 3.16 tarball of jhbuild, to get the documentation updates online, I'll get to it. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME 3.15.92 Release Candidate
Hello all, We have now reached the end of the development cycle and here comes a release candidate for you to download, build, and test. Enjoy it as fast as you can, the final release is scheduled next Wednesday. To compile GNOME 3.15.92, you can use the jhbuild modulesets published by the release team (which use the exact tarball versions from the official release). https://developer.gnome.org/jhbuild/ https://download.gnome.org/teams/releng/3.15.92/ We remind you we are string frozen, no string changes may be made without confirmation from the l10n team (gnome-i18n@) and notification to both the release team and the GNOME Documentation Project (gnome-doc-list@). Hard code freeze is also in place, no source code changes can be made without approval from the release-team. Translation and documentation can continue. More details about changes and news for this beta are available here: core: https://download.gnome.org/core/3.15/3.15.92/NEWS apps: https://download.gnome.org/apps/3.15/3.15.92/NEWS The GNOME 3.15.92 release itself is available here: core sources: https://download.gnome.org/core/3.15/3.15.92/ apps sources: https://download.gnome.org/apps/3.15/3.15.92/ 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.15, the full schedule, the official module lists and the proposed module lists, please see our colorful 3.15 page: https://www.gnome.org/start/unstable For a quick overview of the GNOME schedule, please see: https://wiki.gnome.org/Schedule Enjoy, Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
TARBALLS DUE: 3.15.92
Hi! Tarballs are due on 2015-03-16 before 23:59 UTC for the GNOME 3.15.92 rc release, which will be delivered on Wednesday. [...] Please do your best to keep this Monday deadline, it really helps the work of the release team. Thank you all! Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Canonical jhbuild documentation
Ekaterina Gerasimova wrote: https://wiki.gnome.org/HowDoI/Jhbuild is the one that seems to be preferred by most docs newcomers and team members so from my point of view it would be good that the final result resembles it and works just as well. Also jhbuild has been absorbing good practices first written down in that page (default directory layout, no jhbuilrc required), and that in turn made that page shrink, which is a good thing. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Canonical jhbuild documentation
Germán Poo-Caamaño wrote: IMHO, the jhbuild documentation is more like a reference manual, whereas the information for newcomers is like a tutorial (or expected to be). Indeed it's mostly like that at the moment. Maybe both could be in the same documentation/place, but the separation between both approaches should be clear. That's what I tried, doing at the same time the conversion from docbook to mallard, https://people.gnome.org/~fpeters/jhbuild-mallard/ The introduction text could be make shorter, to bring the getting started part closer to the top. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Canonical jhbuild documentation
Allan Day wrote: It would be nice if somebody could contact the authors: James Henstridge james at jamesh.id.au C.J. Adams-Collier cjcollier at colliertech.org Frederic Peters (ok, done) David Turner (Cillian64, from GHOP, back in 2007/2008, I can't find an email) Oh that's great - thanks Fred. Is there a bug or some other place where the license update is being tracked? We'll need a way to record the consent of the original authors, if I'm not mistaken. There's no tracking for that, but yes there should be. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Canonical jhbuild documentation
Allan Day wrote: People will always come across the official manual on developer.gnome.org, since this ranks highly in search results. So, if you really want people to easily find the introductory documentation, it will have to live as a part of the official manual. I get the The most important thing about the manual that lives in the jhbuild git repository it that it can be translated (currently it's almost fully available in Spanish, Portuguese (_BR), Greek and Japanese). impression that there has been resistance to this in the past, due to the desire to keep Jhbuild as a somewhat generic tool. However, I don't see how the two use cases (Jhbuild for new GNOME contributors, and Jhbuild for everyone else) couldn't be satisfied by structuring the manual according to audience. I believe this is no longer a problem; when I tried to merge the by-then new BuildGnome page into the manual, and converting it to Mallard, the primary problem was of license incompatibility between the contents from the wiki and the existing manual. It would be nice if somebody could contact the authors: James Henstridge james at jamesh.id.au C.J. Adams-Collier cjcollier at colliertech.org Frederic Peters (ok, done) David Turner (Cillian64, from GHOP, back in 2007/2008, I can't find an email) Btw the draft integration/conversion is still available at: https://people.gnome.org/~fpeters/jhbuild-mallard/ Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Canonical jhbuild documentation
Sébastien Wilmet wrote: Hi, On Tue, Feb 10, 2015 at 11:27:11AM -0800, Sriram Ramkrishna wrote: Problem: we have many pages on jhbuild documentation Let's list them: 1. https://wiki.gnome.org/Projects/Jhbuild 2. https://developer.gnome.org/jhbuild/unstable/ 3. https://wiki.gnome.org/GnomeLove/BuildGnome 4. https://wiki.gnome.org/GnomeLove/JhbuildIntroduction 5. https://wiki.gnome.org/HowDoI/Jhbuild …any others? Some projects have specific instructions, a recent one is gnome calendar, https://wiki.gnome.org/Apps/Calendar/JHBuild There is also quite a serie of blog posts depicting various workflows, for example http://blog.desmottes.be/?post/2013/11/08/Building-a-single-module-using-jhbuild Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Tarballs for GNOME 3.15.4
Hi! We are releasing 3.15.4 this week, deadline for tarballs is today, please get them uploaded on time so we can correctly prepare the first release of the year. If you cannot make it, please send a mail to the release team to discuss delays or find someone to roll a tarball. Thanks! Fred [PS: reminder are automatically sent to the devel-announce-list@, if you are a maintainer you should subscribe to it.] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: System services jhbuild
Sriram Ramkrishna wrote: On Mon, Sep 8, 2014 at 9:55 AM, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: Unless someone has plans on fixing this (somehow) soon, I would suggest we either kick out all system services from jhbuild all together or at least remove them from dependency list of other modules. +1 for me, It should try to use what is already on the system. It does (basically it sets PKG_CONFIG_PATH to also look into the system directories, so if you have networkmanager development files installed, it will find them), and it even automatically skip modules that are installed with a proper version (but it has to know the required minimum version, and we used to maintain that appropriately with external deps, less so thosedays). Also, while it's not possible to run system services, it may still be useful to have them in jhbuild, as they provide libraries that will be used by other modules. For example it is required to have accountsservice libraries to build and run gnome-control-center, but most panels will be fine if the service itself is not running. Besides, what is the end goal of jhbuild? Is it to write code against the latest GNOME or is it to build a complete desktop environment? I would argue that we already have gnome-continuous for the latter. Reducing jhbuild's scope would help make it an easier tool to manage and actually work. It would certainly be easier but I don't foresee the double goal of jhbuild changing much, because it still has to fulfil both in some ways (as it's made to run in a VM, I don't feel like gnome-continuous provides an appropriate testing/working environment). Still, we may envision changes; for example it's now possible to have conditional modules, so perhaps we could work to have it both ways, with a default set without the system services, and a flag to enable them, a la jhbuild --conditions=+system-services build. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]
I wrote: There are a few outstanding bugs (old development versions are pruned from the index files but not from the server, and are getting indexed by Google), [...] That particular bug has now been fixed, old development versions are now properly removed from the server; however I don't know how it will play out exactly with Google indexing. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Merge eBooks support in gnome-documents (was Re: New feature proposals period start)
Bastien Nocera wrote: Here goes with a first proposal, I'd like to be able to merge: https://bugzilla.gnome.org/show_bug.cgi?id=704316 This would add a new application to the GNOME release. It's all dependent on Marta providing a viewer widget, though the libgepub[1] maintainer is interested in working on a native one. And it obviously also depends on the gnome-documents maintainers being happy with the path taken, of reusing a majority of gnome-documents' codebase to avoid duplication. Thank you; I started a Feature page: https://wiki.gnome.org/ThreePointFifteen/Features/EBookSupport Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]
Allan Day wrote: One of the reasons why I wanted to have this conversation is to find out if there are any third party solutions that we could use, rather than having to write and maintain our own site from scratch? Is Read the Docs [1] an option? It's a first look from that perspective, I'll be happy to be corrected if I'm wrong in places. It's tailored for Sphinx (http://sphinx-doc.org/) but it has a doc builder abstraction, and it looks like it wouldn't be too difficult to add more types of documents (gtk-doc, mallard, wiki extracts...). I don't see a way to group multiple modules into bundles (a particular set of versions), this is not something we have at the moment but we talked about it in the context of devhelp; this is somehow back to the what do we want to publish? question. It would need some developments but it would certainly be a useful experiment to at least create some proof of concept with it. Do you think it would also be appropriate for help.gnome.org? (as we share the library-web between developer.gnome.org and help.gnome.org) Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]
Hi Shaun, How much maintenance burden is there for the general infrastructure of library-web, versus the burden of the various converters and such that we'd have to deal with anyway if plugging them into another system? There's not much maintenance required, for example new modules are automatically picked up from the jhbuild modulesets, as well as new versions of known modules published on ftp.gnome.org. There are a few outstanding bugs (old development versions are pruned from the index files but not from the server, and are getting indexed by Google), and nobody to look at them regularly (I have been doing most of library-web work during hackfests), maybe because it's difficult to hack on, but mostly (imho) because there are very few persons working on infrastructure, documentation, or both. RTD has been hugely popular in the Python world, but it's not the only continuous deployment or automated docs build system out there. Red Hat and Fedora use Publican for almost everything. OpenStack has a big pile of Maven code that builds its site. There are plenty of other examples that I could dig up. Indeed; as I wrote earlier I'd prefer to have ideas on the structure we want before we go looking for the appropriate software (or changes to the library-web code base). Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]
Allan Day wrote: However, before we go down that route, it seems like we should at least discuss whether library-web is the best option going forward. It I would tend to put goals before technical details, but library-web as it is nowadays is certainly not the best option; I addressed a few of the issues in my mail to gnome-doc-devel-list@. * Hackability - from what I've seen, it is very difficult for people to hack on developer.gnome.org. The barrier to entry is high, documentation is lacking, and it all seems rather obscure. There's some documentation, and it's even up-to-date up to the point that several persons got it running locally, but it has a long hack/build cycle by default (as it will cover all modules from multiple GNOME releases), and is using XSL transformations, and many persons find this arcane. That structure made sense back in the day (2006) but given the way other tools evolved (gtk-doc, yelp-tools), and better sysadmin infrastructure (it was difficult to get new packages installed on the RHEL version that was used until recently), it should be done differently now. * User experience - we need to decide whether developer.gnome.org should look and feel like a static website, or should be more like a web app. I was looking at Read the Docs [1] a while ago, and that kind of experience seemed like a good fit for API docs especially - search is prominent, you can quickly switch between documentation, etc. I gave my opinion in that previous email, I'd go with a dynamic website, as this would solve the issue of stale files, and offer better ways to integrate important things, like search. (the stale files issue is the problem Jasper talked about, we get Google indexing files way suboptimally) * Documentation writing workflow. Monolithic modules written in Mallard, like gnome-devel-docs, aren't approachable for developer documentation writers. The HowDoI series has been reasonably successful, partly because it is easy to write documentation on the wiki, but finding and navigating that material isn't great [2]. A middle ground might be appropriate (Markdown HowDoIs, perhaps). There are several layers here, most of the documentation still comes from C files, via gtk-doc, then from docbook, gtk-doc again. This is the bulk of what gets published, even for more textual content (migrating from GTK+ 2.x to GTK+ 3 for example); then we have other HTML generators, like Doxygen for the C++ bindings. The other documents, the Mallard pages in the platform overview or developer demos, the few wiki pages, are a really tiny part. But to be honest, while the workflow can definitely be improved, I don't think it's the main obstacle. I look at user documentation, it gets written, it gets updated, and it's Mallard in git repositories. No, I think the obstacle is that we don't have enough people willing to work on developer documentation over something else, even though many will recognize the importance it has. It's not new. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]
Jasper St. Pierre wrote: While I'm sure a dynamic site would be a great idea in the far future, are there any small, actionable goals we can make for this? We all dream of a great docs scenario, but we never properly plan for it. What small wins can we get today, right now, to improve the experience? I have some free time to hack on it. There's a bunch of tasks over there: https://wiki.gnome.org/DocumentationProject/Tasks/DeveloperDocs#developer.gnome.org You will also find some in bugzilla, product: website, component: developer.gnome.org. Most items are about classification, it's mostly actioned via a single file in library-web: https://git.gnome.org/browse/library-web/tree/data/overlay.xml.in Add a section for C++ Development (put this at the bottom of the page). Move the links to the programming with gtkmm3, libsigc++ and libxml++ pages to this section. The page is https://developer.gnome.org/guides. That page is defined by this snippet: subindex id=guides weight=1 sectionsoverview gdp-documentation tutorials faqs devel-guides ApplicationsProgramming/sections _titleGuides/_title _abstract A growing selection of development guides on common topics. /_abstract /subindex We want a new section, we add c++-development to the sections tag; then we want to define it, and want it at the bottom, subsection channel=devel id=c++-development weight=0.1/ And we need to give it a proper title, it's in another file, catalog.xml.in so it can be translated, we add a new line: _msgstr msgid=c++-developmentC++ Development/_msgstr Then we want some content in that section, we find the Programming with gtkmm link, document doc_module=gtkmm-tutorial old-channel=users channel=devel categorydevel-guides/category /document and change its category, from devel-guides to c++-development. Then we do the same thing for libsigc++ and libxml++ tutorials, and we're done with that item. Voila, I didn't do it for real, I may have made some typo but that's the general idea; of course there's the hackability problem, it takes time to have an exact mirror of developer.gnome.org running locally but it's probably not needed. Don't hesitate to file bugs with patches, I'll review them quickly. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
TARBALLS DUE: 3.13.2.
Hello all, Maybe this went unnoticed but we (release team) published the schedule for 3.13 a few weeks ago, it's at https://wiki.gnome.org/Schedule. And guess what? We expect tarballs today; in the words of our usual emails: Tarballs are due on 2014-05-26 before 23:59 UTC for the GNOME 3.13.2 unstable release, which will be delivered on Wednesday. Modules which were proposed for inclusion should try to follow the unstable schedule so everyone can test them. Please make sure that your tarballs will be uploaded before Monday 23:59 UTC: tarballs uploaded later than that will probably be too late to get in 3.13.2. If you are not able to make a tarball before this deadline or if you think you'll be late, please send a mail to the release team and we'll find someone to roll the tarball for you! Cheers, Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
TARBALLS DUE: 3.12.2
Hello all, Now is the time for a new update to our stable release, this is 3.12.2. Tarballs are due on 2014-05-12 before 23:59 UTC for the GNOME 3.12.2 stable release, which will be delivered on Wednesday. Modules which were proposed for inclusion should try to follow the unstable schedule so everyone can test them. Please make sure that your tarballs will be uploaded before Monday 23:59 UTC: tarballs uploaded later than that will probably be too late to get in 3.12.2. If you are not able to make a tarball before this deadline or if you think you'll be late, please send a mail to the release team and we'll find someone to roll the tarball for you! For more information about 3.13, the full schedule, the official module lists and the proposed module lists, please see our colorful 3.13 page: http://www.gnome.org/start/unstable For a quick overview of the GNOME schedule, please see: https://wiki.gnome.org/Schedule Cheers, Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
TARBALLS DUE: GNOME 3.12.1
Hello all, Isn't running 3.12 sweet? Did you see the comments? Christian Schaller collected some, full of superlatives, have a look: http://blogs.gnome.org/uraeus/2014/04/02/gnome-3-12-release-comments/ But it doesn't end there, the new step is the 3.12.1 update release, and we need tarballs on Monday: Tarballs are due on 2014-04-14 before 23:59 UTC for the GNOME 3.12.1 newstable release, which will be delivered on Wednesday. Modules which were proposed for inclusion should try to follow the unstable schedule so everyone can test them. Please make sure that your tarballs will be uploaded before Monday 23:59 UTC: tarballs uploaded later than that will probably be too late to get in 3.12.1. If you are not able to make a tarball before this deadline or if you think you'll be late, please send a mail to the release team and we'll find someone to roll the tarball for you! For more information about 3.11, the full schedule, the official module lists and the proposed module lists, please see our colorful 3.11 page: http://www.gnome.org/start/unstable For a quick overview of the GNOME schedule, please see: http://live.gnome.org/Schedule Cheers, Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
TARBALLS DUE: GNOME 3.12.0
Hello all, With 3.11.92 out, it's time for 3.12.0 tarballs. Let the translations flow into your modules then get your tarballs out. Tarballs are due on 2014-03-24 before 23:59 UTC for the GNOME 3.12.0 newstable release, which will be delivered on Wednesday. Modules which were proposed for inclusion should try to follow the unstable schedule so everyone can test them. Please make sure that your tarballs will be uploaded before Monday 23:59 UTC: tarballs uploaded later than that will probably be too late to get in 3.12.0. If you are not able to make a tarball before this deadline or if you think you'll be late, please send a mail to the release team and we'll find someone to roll the tarball for you! For more information about 3.11, the full schedule, the official module lists and the proposed module lists, please see our colorful 3.11 page: http://www.gnome.org/start/unstable For a quick overview of the GNOME schedule, please see: http://live.gnome.org/Schedule Cheers, Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
TARBALLS DUE: GNOME 3.11.92 release candidate + HARD CODE FREEZE
Hey all, Here comes the 3.11.92 release candidate, last stop before 3.12. Tarballs are expected on Monday, this is the last chance to get your fixes in, we will then enter the hard code freeze, and you will need a big bunch of approvals to get changes in. Let's repeat, tarballs are due on 2014-03-17 before 23:59 UTC for the GNOME 3.11.92 rc release, which will be delivered on Wednesday. Please make sure that your tarballs will be uploaded before Monday 23:59 UTC: tarballs uploaded later than that will probably be too late to get in 3.11.92. If you are not able to make a tarball before this deadline or if you think you'll be late, please send a mail to the release team and we'll find someone to roll the tarball for you! We will be entering the HARD CODE FREEZE: This is a late freeze to avoids sudden last-minute accidents which could risk the stability that should have been reached at this point. No source code changes are allowed without approval from the release team, but translation and documentation should continue. Simple build fixes are, of course, allowed without asking. For more information about 3.11, the full schedule, the official module lists and the proposed module lists, please see our colorful 3.11 page: http://www.gnome.org/start/unstable For a quick overview of the GNOME schedule, please see: http://live.gnome.org/Schedule Cheers, Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Python Docs (was Re: Coordination for developer documentations)
Stefan Sauer wrote: On 03/08/2014 06:15 PM, Christoph Reiter wrote: I've tried the devhelp export and it seemed to work quite well for the all in one API docs. But I'm not sure how linking between different Sphinx builds would work with devhelp. (but I have no idea how devhelp does it with other sources either..) devhelp is basically the index.sgml (ignore the sgml extension, it is not) + prerendered html. devhelp does not do anything with the link in the html doc, except trying to follow them when one is clicked. Indeed, the pages rendered by devhelp are HTML pages taken straight from the filesystem, with no transformation at all. As I wrote to Giovanni earlier, it would certainly be possible to reuse YelpView, to get support for Mallard files. Next to the document view, for the tree of documents and the keyword search, devhelp requires a file in its own '.devhelp2' xml format; it's actually quite simple, it goes like this: ?xml version=1.0 encoding=utf-8 standalone=no? book xmlns=http://www.devhelp.net/book; title=GTK+ 3 Reference Manual link=index.html author= name=gtk3 version=2 language=c chapters sub name=GTK+ Overview link=gtk.html sub name=Getting Started with GTK+ link=gtk-getting-started.html sub name=Basics link=gtk-getting-started.html#id-1.2.3.3/ ... /chapters functions !-- functions -- keyword type=function name=gtk_dialog_run() link=GtkDialog.html#gtk-dialog-run/ !-- but also other types keyword type=struct name=struct GtkApplicationClass link=GtkApplication.html#GtkApplicationClass/ !-- possibility to mention when it got added -- keyword type=enum name=enum GtkApplicationInhibitFlags link=GtkApplication.html#GtkApplicationInhibitFlags since=3.4/ !-- and also when it got deprecated -- keyword type=function name=gtk_dialog_set_alternative_button_order() link=GtkDialog.html#gtk-dialog-set-alternative-button-order deprecated=3.10: Deprecated since=2.6/ Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announce: Gjs documentation almost ready!
Giovanni Campagna wrote: 1) are there plans to get this into devhelp? We need to figure a namespace scheme for binding docs. The devhelp app itself already understands different languages. All we need is a index file like the ones gtk-doc generates. No, there are no plans to get this in devhelp. The HTML output is really just a way to get them somewhere in the internet without blocking on library-web, but the real deliverable is mallard, and devhelp does not understand that (while library-web does) If the HTML output is somehow distributed, or can be built with minimal tooling (i.e. not a complete GNOME build environment), they can certainly be integrated into developer.gnome.org. You can file bug reports against product: website, compotent: developer.gnome.org. The situation is roughly the same for Devhelp, if HTML files are distributed it's easy for Devhelp to display them; displaying the Mallard files directly is certainly more difficult, maybe it's possible to use libyelp YelpView. Anyway, bug reports are welcome. Thanks, Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Coordination for developer documentations
Hey, It's been proved again in recent hackfests, we have a really great team writing user documentations, and thanks have to be given to Shaun, and now Kat, for coordinating the effort. On the other hand we have absolutely no coordination for developer docs, I maintain developer.gnome.org with the little time I have, Aleksander helps with Devhelp, there are some punctual changes from various persons, David maintains gnome-devel-docs, Tomeu did work on generating python documentation from gobject-introspection a while ago, Giovanni did it for gjs recently, Jon improved markdown support in gtk-doc, etc. but all this happens without coordination and it happens people step on each other's toes, and it hurts. Developer documentation will be a topic during the Developer Experience Hackfest, but I believe we will fail again to provide lasting effects if nobody takes on a coordination role. So, are you interested? Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Coordination for developer documentations
Hi Allan, Allan Day wrote: So, are you interested? It would help to know a bit more about what you think this coordination role would involve. Are you concerned with keeping technical changes in step, for example, or is it more the content in our hand written documentation that we need to be careful about? 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. A recent example is the way gtk-doc comments are written, and how to accomodate them in order to provide meaningful comments when reused for other languages (references to manual memory management for example). Maybe the concerned parties just need to be made aware of how their work might affect others? Or maybe the dependencies between components need to be more clearly spelled out? Given a vision I believe it will be necessary to coordinate whatever needs to be done to get to it, having various persons giving the subject a bit of their time sporadically won't work out (that's what we've been doing since at least the Berlin hackfest more than four years ago). Maybe we do not need a person, maybe tools (like the gnome-devel-doc list) are enough to get the required coordination, but from what I've seen of the documentation team, a dedicated and focused person really helps. So I agree with you, the first is certainly to get that common vision nailed down. But then, having a solid developer documentation team, rather than various individuals, would help tremendously, in defining the vision, and working towards it afterwards. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
TARBALLS DUE: GNOME 3.11.5
Hello all, It's FOSDEM weekend, if you're there, come and say hi! to the GNOME booth. Tomorrow, after you safely got home, it will be time to roll some tarballs for 3.11.5. You know the drill: Tarballs are due on 2014-02-03 before 23:59 UTC for the GNOME 3.11.5 unstable release, which will be delivered on Wednesday. Modules which were proposed for inclusion should try to follow the unstable schedule so everyone can test them. Please make sure that your tarballs will be uploaded before Monday 23:59 UTC: tarballs uploaded later than that will probably be too late to get in 3.11.5. If you are not able to make a tarball before this deadline or if you think you'll be late, please send a mail to the release team and we'll find someone to roll the tarball for you! For more information about 3.11, the full schedule, the official module lists and the proposed module lists, please see our colorful 3.11 page: http://www.gnome.org/start/unstable For a quick overview of the GNOME schedule, please see: http://live.gnome.org/Schedule Cheers, ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Fix wrong FSF's address in in source files
Hi Daniel, devhelp I didn't find a bug report for this one, please do file one and I'll have a look. jhbuild https://bugzilla.gnome.org/show_bug.cgi?id=721532 feel free to attach a patch and it will be quickly reviewed. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
TARBALLS DUE: GNOME 3.11.4 due on Monday January 13th
Hello all, The work towards 3.12 continues in 2014, this is the first call for tarballs this year, happy new year! Tarballs are due on 2014-01-13 before 23:59 UTC for the GNOME 3.11.4 unstable release, which will be delivered on Wednesday. Modules which were proposed for inclusion should try to follow the unstable schedule so everyone can test them. Please make sure that your tarballs will be uploaded before Monday 23:59 UTC: tarballs uploaded later than that will probably be too late to get in 3.11.4. If you are not able to make a tarball before this deadline or if you think you'll be late, please send a mail to the release team and we'll find someone to roll the tarball for you! For more information about 3.11, the full schedule, the official module lists and the proposed module lists, please see our colorful 3.11 page: http://www.gnome.org/start/unstable For a quick overview of the GNOME schedule, please see: http://live.gnome.org/Schedule Cheers, Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME 3.12 Schedule and 3.11.1 tarballs call
Hello all, I just published our schedule for 3.11/3.12 on our wiki, it's available at: https://wiki.gnome.org/ThreePointEleven, tarballs for next release, the opening of the 3.11 cycle, are expected on Monday. Fred [An ics file is also available: https://www-old.gnome.org/start/schedule-unstable.ics ] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
3.10.1 coming up!
Hey all, It was not announced with the usual template but we need your tarballs for 3.10.1, Matthias Clasen wrote: After catching our breath for a while, and enjoying 3.10.0, now it is time to put out a 3.10.1 release to fix annoyances and bugs that have come up since 3.10.0. I have marked a few bugs as candidates for fixes to include in 3.10.1 - I hesitate to call them blockers, since many of them are not that serious. But still, it would be nice to fix some of these before rolling the 3.10.1 tarballs next Monday. So go for it, and let's make it shine. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Opening the 3.12 cycle
Zeeshan Ali (Khattak) wrote: But apparently its the only free OS worth caring about. I think Jasper was asking about distros as I'm pretty sure he is well aware that systemd doesn't run on an archaic OSs, such as FreeBSD. No need to be insulting. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Opening the 3.12 cycle
Michael Catanzaro wrote: On Mon, 2013-09-23 at 09:09 -0400, Matthias Clasen wrote: I think that would be a great idea - could you set up the goal wiki page and link it from the gnome-software feature ? The goal should include that all appdata is marked for translation. This could also come after a review of the appdata schema, for things like screenshot translations. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Passive resistance [was: Re: Announcing GNOME's official GitHub mirror]
Jasper St. Pierre wrote: If you're not happy with that, we can certainly bring it up to the board and talk about it, but from how I see things, I don't think we'll remove GNOME Online Accounts integration or stop our Twitter marketing campaigns. So, I'm saying that if you're not happy with those directions, I think GNOME may not be the best place for you. Or we can keep on working in GNOME, and encourage developments such as the Owncloud support that got added to GNOME Online Accounts. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: A first look at 3.10 blockers
Thanks Matthias for starting this. Related to system status rework: - 705647 gnome-shell New System Status design lost the ability to suspend 705733 gnome-shell Make new system status implementation respect the always-show-universal-access-status setting I'd consider one of those to be a blocker: - 705104 / gnome-shell / new network menu has no way to select a wired connection - 705935 / gnome-control-center / make it possible to connect to alternate connections Both of them probably needs designer input. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git submodules vs translators
Colin Walters wrote: Any other thoughts? https://bugzilla.gnome.org/show_bug.cgi?id=599066 is the request by translators to be able to auto-commit files from damned lies, from 2009. It would help here. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: jhbuild: better defaults
Thomas H.P. Andersen wrote: Are there non-bikeshed reasons not to do this? Are there things that will break so bad that the cost outweigh the benefit? Patch welcome; but do mind this comment: The only slightly tricky thing about this I see is detecting the case where the user was actually using the default in defaults.jhbuildrc, in other words if you had just an empty .jhbuildrc and were *actually* using /opt/gnome for installs. -- Colin Walters https://bugzilla.gnome.org/show_bug.cgi?id=655714#c1 Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME goal for 3.8: Python 3 -- impact for pygobject itself
Colin Walters wrote: The whole thing is just so horrible...Python upstream should have just accepted they made a different (but closely related) programming language and said python is always python2, and python3 is 3, or they should have made a python2 symlink upstream for the old branch, so python2 users knew where to find it reliably. This happened a bit late but http://www.python.org/dev/peps/pep-0394/ defines exactly this. This PEP provides a convention to ensure that Python scripts can continue to be portable across *nix systems, regardless of the default version of the Python interpreter (i.e. the version invoked by the python command). - python2 will refer to some version of Python 2.x - python3 will refer to some version of Python 3.x - python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
William Jon McCann wrote: I agree with you that we need to have a motive to change and that costs should be weighed carefully. We can make the case. The objection Colin expressed was about the method; and on that matter, frankly, we are making a good job in alienating active members of our community, to the point our GNOME is people is no more but a slogan.[1] We have active members using Debian, Ubuntu, Gentoo, OpenBSD, whatever, for whatever *good* reasons, and more often than not they will have nothing to do with GNOME. You may not want to compromise with code, I want to compromise with people, this definitely takes longer, this takes emails, this takes discussions, this is in my opinion important. And this certainly doesn't mean we are not going forward. Fred [1] let's wait for somebody to register gnomeispeople.org and put a big no, it's not on it... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
Bastien Nocera wrote: Additionally, and separately, support for ConsoleKit usage for session-tracking will be removed. This is now pushed to master for 3.7.1. Well, this all happened a few days before the release deadline, this is not easy matter, we have a release team meeting this week-end and we will talk about the whole situation. Of course this is still just 3.7.1, but anyway. I'd suggest we do *not* ship gnome-settings-daemon 3.7.1 in GNOME 3.7.1 and wait for a project-wide decisionon how support of ConsoleKit systems should be (dis)continued. Fred [1] those kind of decisions were the subject of the release team part our AGM in GUADEC... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Blocker bug status
Germán Póo-Caamaño wrote: 683354 Port to new documentation infrastructure AFAIK, there is a fair concern on this because of the potential impact on translations: shaunm I'm tempted to just say push it, and if there's anything wrong I'll catch it making a release shaunm but I'm a little concerned about needlessly breaking translations this late shaunm because itstool and xml2po can produce different messages in some cases shaunm can we check that easily? Shaun checked that and commented in the bug report, it appeared this would invalidate too many strings to do it now, postponed for 3.7. https://bugzilla.gnome.org/show_bug.cgi?id=683354#c2 Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME 3.6 Blocker Report (T-16d)
Hello all, We are now well frozen, it's more than time for a new blocker report; have a look at the list below and do note the list below is not necessarily complete. Feedback, updates, help from packagers, developers, maintainers, contributors, etc. is welcome. Please do speak up if some important bugs are not listed here, or if some tickets should not be blockers. Note: This list also includes open reports that still have a 3.4 target. Fred ANJUTA == - Port to new documentation infrastructure https://bugzilla.gnome.org/show_bug.cgi?id=683308 Last bit of the 'new doc infra' goal, patch available. EMPATHY === - Port to GStreamer 0.11/1.0 https://bugzilla.gnome.org/show_bug.cgi?id=674179 Empathy is now ok, bug still open to track availability of farsight releases and some GStreamer bugs. EVINCE == - libsecret migration https://bugzilla.gnome.org/show_bug.cgi?id=679855 Rough unfinished patch available. GNOME-BACKGROUNDS = - New background Stamps with a stamp of Marshal Tito https://bugzilla.gnome.org/show_bug.cgi?id=683444 GNOME-CONTROL-CENTER - Wireless list - arrow button is undiscoverable and hard to activate https://bugzilla.gnome.org/show_bug.cgi?id=682270 No activity here. GNOME-DEVEL-DOCS - Port to new documentation infrastructure https://bugzilla.gnome.org/show_bug.cgi?id=683354 Last bit of the 'new doc infra' goal, patch available. GNOME-SESSION = - gnome-session no longer starts desktop files under /usr/share/gdm/autostart/LoginWindow https://bugzilla.gnome.org/show_bug.cgi?id=663721 - shell crashed at login and ended up in a dead end session https://bugzilla.gnome.org/show_bug.cgi?id=672419 One more patch left to do. Ray? GNOME-SETTINGS-DAEMON = - Maximum 3D size limitations https://bugzilla.gnome.org/show_bug.cgi?id=646280 Owen has now looked into this and Adam Jackson provided for a patch for gnome-session, as I understand it, it still needs some patch to gsd. - power: enforcing lid close https://bugzilla.gnome.org/show_bug.cgi?id=680689 GNOME-SHELL === - restart by typing r in the gnome-shell run-dialog 2x in one minute brings up the oops window https://bugzilla.gnome.org/show_bug.cgi?id=648384 - Be able to ask for IM account password https://bugzilla.gnome.org/show_bug.cgi?id=658961 - Alt-F2 + mouse middle button paste causes freeze https://bugzilla.gnome.org/show_bug.cgi?id=676918 No progress here. - libsecret migration https://bugzilla.gnome.org/show_bug.cgi?id=679851 Rough unfinished patch available. - 3.5.5: Lock screen shows password for a few characters / max 1 second https://bugzilla.gnome.org/show_bug.cgi?id=681576 - top left corner turns cold when message tray is displayed https://bugzilla.gnome.org/show_bug.cgi?id=682255 - 3.5.90: keyring prompt can't be confirmed or cancelled https://bugzilla.gnome.org/show_bug.cgi?id=682830 - Impossible to unlock screen if not using GDM https://bugzilla.gnome.org/show_bug.cgi?id=683060 A patch is now available so the user at least doesn't get stuck at the lock screen. Lockscreen functionality is still lost for users that are not running GDM 3.6. - 3.5.90 - Nine dot application ICON drops off Dash https://bugzilla.gnome.org/show_bug.cgi?id=683340 - 'tray' button doesn't work with new message tray https://bugzilla.gnome.org/show_bug.cgi?id=683545 - notification does not work with new message tray https://bugzilla.gnome.org/show_bug.cgi?id=683546 GNOME-THEMES-STANDARD = - Nautilus tabs have black background https://bugzilla.gnome.org/show_bug.cgi?id=682395 GSTREAMER = - [0.11] pulsesrc breaks when reconfiguring https://bugzilla.gnome.org/show_bug.cgi?id=681247 Blocker for Empathy. - v4l2src breaks after renegotiation https://bugzilla.gnome.org/show_bug.cgi?id=682770 Blocker for Empathy. GTK+ - [regression] crash on exit https://bugzilla.gnome.org/show_bug.cgi?id=671939 Patch available. Help welcome to bisect and write a test case for the TreeView test suite. - smooth scrolling could do with some optimizations https://bugzilla.gnome.org/show_bug.cgi?id=672091 There has been a commit that could help, needs confirmation. - Commit 7603e6e4 breaks setting background-image from cairo pattern https://bugzilla.gnome.org/show_bug.cgi?id=672858 - Code that gives me a spinner in gtk+ 3.4.4 does not in 3.5.8 https://bugzilla.gnome.org/show_bug.cgi?id=680980 LIBSOUP === - drop SoupPasswordManagerGNOME https://bugzilla.gnome.org/show_bug.cgi?id=679866 Related to the libsecret migration. MUTTER == - GtkWindows (comboboxes, menus, etc.) do not show up on primary display https://bugzilla.gnome.org/show_bug.cgi?id=672163 Partial fix committed. NAUTILUS -
String Freeze
Hello all, The string freeze has set in, no string changes may be made without confirmation from the i18n team and notification to release team, translation team, and documentation team. From this point, developers should concentrate on stability and bug-fixing. Translators can work without worrying that the original English strings will change, and documentation writers can take accurate screenshots. For the string freezes explained, and to see which kind of changes are not covered by freeze rules, check this page: http://live.gnome.org/TranslationProject/HandlingStringFreezes. It's also important to make sure that your module's po/POTFILES.in and po/POTFILES.skip are correct and uptodate and that no source files are lacking from these files. For more information about 3.5, the full schedule, the official module lists and the proposed module lists, please see our colorful 3.5 page: http://www.gnome.org/start/unstable For a quick overview of the GNOME schedule, please see: http://live.gnome.org/Schedule Cheers, Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: jhbuild update required
Colin Walters wrote: On Wed, 2012-09-05 at 15:13 -0400, Jasper St. Pierre wrote: On Wed, Sep 5, 2012 at 3:10 PM, Jeremy Bicha jbi...@ubuntu.com wrote: Could we get a new jhbuild release then? Some distributions (Debian, Ubuntu, openSUSE) have jhbuild packaged in their repositories. jhbuild is not meant to be packaged. I'd highly suggest you stop packaging jhbuild. Well...there are some good and bad things about packaging jhbuild. The bad thing is that there's often a large lag time before packages are updated. The good thing is it's easier to install. Craig, any thoughts on doing a release? I just pushed a 3.5.91 tarball. @Jasper: jhbuild packages can be quite useful to get core dependencies installed (git, autotools, etc.), I'd encourage them. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Recommended office suite?
Mattias Eriksson wrote: I noticed that the Gnome Ubuntu flavor will not ship libreoffice, but instead only ship Abiword and Gnumeric. I was surprised by this, since I think libreoffice is the best office suite for linux and it has quite good gnome integration. The motivation for this is that they want to provide a pure gnome experience, and these applications are referenced in the gnome-app module set. However, I haven't seen any talk about Abiword and Gnumeric on the gnome mailinglists or on planet.gnome.org for quite a while (I actually was under the impression that these projects had been abandoned). While I do not actively follow the development of abiword, I can assure you gnumeric, and the goffice support library, are still under active development, with several active commiters. As a personal preference I use gnumeric over LibreOffice Calc and it does have all the features, and more, that I want. Give it a try. But I use LibreOffice Writer, it works great and fits the environment. I'm also under the impression that there are a lot of support for LibreOffice in the Gnome community, and I was told that Documents has a dependency on it (causing Documents not to be included in the Gnome Ubuntu flavor). I do not know of such a dependency. So my question is: What is the recommended office suite for a pure gnome experience? What has been talked about for the up coming Gnome OS? GNOME by itself doesn't ship an office suite. You have seen the different projects, some are closer to GNOME, for technical or personal reasons, but none are officialy endorsed http://www.gnome.org/applications/ If you like LibreOffice, certainly Ubuntu doesn't prevent you from installing it, and it will work, don't worry about it, and please do not worry about what is pure or not. As for GNOME OS, it is primarily intended as a platform for testing and development, not the system where you'll do your daily work in spreadsheets and text documents; there is much to resolve there before we get to talk about an official office suite. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
relative URLs for git submodules
Hello, Several GNOME modules have started using git submodules, for example there is empathy, using egg-list-box: [submodule libempathy-gtk/egg-list-box] path = libempathy-gtk/egg-list-box url = git://git.gnome.org/egg-list-box This works fine, with proper calls to git submodule init and git submodule update added to autogen.sh Another module would now be gnome-font-viewer, it uses: [submodule libgd] path = libgd url = ../libgd And this also works fine, but only if you get your clone from git.gnome.org, if you get it from somewhere else, there is a good chance that ../libgd won't exist. [1] The only advantage I perceive in using a relative URL is that you get the submodule clone over the same transport than the main module, and this is nice if you want to also hack on the submodule (as git:// is readonly). However it's always time to update the remote branch URL after the fact, to use ssh://. Are there other advantages? If not, could we decide to always use full URLs? Fred [1] of course other git hosting services comes to mind, but this also affects jhbuild ability to maintain a dvcs mirror, this is bug 682516 and this is what prompted this message. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: compiler warnings, -Werror, etc.
Colin Walters wrote: For compiler warning defaults, I think something similar what Dan Winship has in libsoup is what we should replicate across more GNOME modules: http://git.gnome.org/browse/libsoup/tree/configure.ac?id=f5902fce98ae0314f0d9ca6e544895548c94a456#n339 It's better than the GNOME_COMPILE_WARNINGS macro in gnome-common right now, and *definitely* better than various modules having -Wall -Werror. Is there some problem in fixing that macro? It would instantly fix dozens of modules (over 50 according to a quick grep). Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libsecret migration
Hi Stef, On 06/27/2012 06:56 PM, Olav Vitters wrote: On Wed, Jun 27, 2012 at 06:49:13PM +0200, Stef Walter wrote: http://people.gnome.org/~stefw/libsecret-docs/c-examples.html Please have that put on http://library.gnome.org. Yes, that's something I need to do. Do you know where I can find documentation for how to do that? Looked in all the obvious places. File a bug against product: website, component: developer.gnome.org, include a small paragraph about libsecret. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: IBus/XKB integration
Tomas Frydrych wrote: Rather a long discussion over IBus, but it seems to more or less boil down to two voices and this: Gnome developers: we want tighter IM integration and simpler UI in the name of better UX, and are looking at IBus as the underlying technology, Users: IBus has poor support for CJK input and a history of not addressing these problems. You may be a bit harsh on IBus, but I believe your characterisation of the GNOME developers view point is quite correct, we do want input methods to be integrated, we do believe this will lead to a better user experience, and certainly this belief doesn't come out of thin air but from discussions with actual CJK users. This feature is called IBus/XKB integration but this is technospeak, what it is really about is to get CJK input methods out of their second-class zone, to bring their integration on the same level as the current XKB support. It happened discussions were engaged with IBus developers, I don't know the history behind this; this thread questions that technical choice, there are important voices from actual CJK users that should not be ignored. The voices of graphic designers are not ignored when they say it's important to be able to configure the meanings of the buttons of their Wacom tablet, but that happens because they are already close to the development of GNOME, while we notoriously lack developers from Asia (hopefully the efforts of GNOME.asia will bear fruits here). But short of that actual experience, what can be done? Just like it happens for other aspects of our development, did we gather relevant art from other platforms? Would it be useful? https://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/InputLanguage doesn't have any of this, perhaps it's elsewhere on the wiki but I didn't find it. I found the videos posted by Justin Wong very instructing, are there moments where designers, developers, CJK users could meet to plan things ahead, GNOME.asia happens next month but I don't think enough of the core developers and designers are going there, but later on there is GUADEC, will we have CJK users there? But then waiting for GUADEC is perhaps too much, that would mean we wouldn't get that feature for 3.6, but perhaps it's worth to wait to make sure the target audience, CJK users, have enough occasion to bring their feedback and to participate in the actual design. Should we step back for now? And how will we then go ahead? Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: IBus/XKB integration
Jasper St. Pierre wrote: We only have the development resources to ship one input method. It's going to need special code to integrate with Clutter and the St toolkit. If IBus is bad right now, we need to fix it. Or use fcitx instead of IBus? I honestly do not know the topic, but I read the emails from Marguerite Su and believe she brought important points. I'd like to understand what are the plus points of IBus today. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: IBus/XKB integration
Bastien Nocera wrote: I don't know of a physical keyboard layout that has a Compose key. So are we just deciding that one of the keys will always behave differently than the printed keycap? I suppose if you use a modifier key (R_Alt seems popular) then it can still function as a modifier as well as Compose, though that will interact poorly with sticky keys. The usual compose key for Western European keyboards is Alt-Gr. That's just one more data point to add to that whole list. On my totally standard french layout, AltGr is used to type the key ternary character; I just checked and setting it to be the Compose key breaks that access. Fred (using the right Ctrl key for Compose) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Seif Lotfy wrote: So I would still like to have my question answered. How is the policy on using Zeitgeist for non-feature and non-UX related optimization and maintenance distribution? Do note this was not discussed by the release team, we'll have a meeting soon and we can add that to the agenda if you want an official answer, but in my opinion there is no problem if a maintainer wants to use zeitgeist because it helps in whatever s/he is coding. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Shaun McCance wrote: Your previous email seems to indicate that the features for 3.6 are already a foregone conclusion, and that Zeitgeist doesn't fit into that. But that just can't be, because WE the GNOME community decide what's in the next version right here on d-d-l during the proposal period. Indeed, there have been a few pages added on the wiki[1], some ported from 3.4, but it would really help the discussion if proponents were to send emails to this list. Also if there are features under discussion that are not listed over there, please add them, and bring the discussion over here. Thanks, Fred [1] https://live.gnome.org/ThreePointFive/Features ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prevent screen from going to sleep
Emmanuele Bassi wrote: On 1 March 2012 09:24, Marco net...@lavabit.com wrote: Any application which e.g. plays a movie can block the screen from turning off. When I watch movies in VLC the screen is still switched off after ten minutes. Preferences → Advanced → “Inhibit the power management daemon during playback” is activated. Maybe that is related to my problem. I'd suggest you file a bug against VLC in their bug tracking system. FWIW http://trac.videolan.org/vlc/ticket/4739 Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: udisks2 [WAS: Re: datetime: Remove datetime D-Bus mechanism]
David Zeuthen wrote: @David: could you confirm this? And do you have any ETA for a udisks2 tarball? There is one at http://udisks.freedesktop.org/releases/ http://www.freedesktop.org/wiki/Software/udisks still points to http://hal.freedesktop.org/releases/, could you update that page? Thanks! Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
Bastien Nocera wrote: And have a Provides: systemd-services in the systemd RPM. The problem isn't exactly insurmontable. Of course it's not insurmontable, but this thread came to be more about proper communication than technical solutions. So far we had 1) the update of the portability matrix, and 2) the acknowledgment a mail should have been sent to distributor-list@; I believe this is satisfactory. Ideally we'd also have earlier notifications, and a list of D-Bus API we depend on (like we had the external dependencies page), but that's more work, and not always feasible. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
udisks2 [WAS: Re: datetime: Remove datetime D-Bus mechanism]
Johannes Schmid wrote: Short note: I removed the udisks and upower rows as they don't follow the system of showing the part of GNOME using some technologie. Instead those are referred to by the gnome-disk-utility and gnome-control-center/power rows which is IMHO the correct way. Speaking of udisks, gnome-disk-utility has now been switched to use udisks2; I can only guess gvfs will follow. @David: could you confirm this? And do you have any ETA for a udisks2 tarball? Fred [breaking thread on purpose] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libwacom dep
Hey Bastien, FYI, moved the git repo to be under the linuxwacom project in sourceforge (one of the few still there I guess, updated in ), and made a tarball release: https://sourceforge.net/projects/linuxwacom/files/libwacom/ It's (technically) required for modules that are defined as coming from git in the jhbuild modulesets to have their tarballs published on ftp.gnome.org; could you host a copy there? Thanks, Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Boxes and 3.4
Jason D. Clinton wrote: When did this happen? I admit I've been a bit disconnected for a few months but even if the Featured Apps didn't get updated, it was never intended to be an exhaustive list. In fact, I explicitly stated in the announcement (with blessing from the Release Team) that there was no mechanism by which to apply for featured status and it was to be construed as nothing more than what it was: purely a marketing designation. There were only 8 Featured Apps the 3.0 and 3.2 release (these eight http://www.gnome.org/applications/) *and* we still had an apps moduleset for both releases. But what's the meaning of the apps moduleset? It is not about featured apps, as you wrote earlier: This list is not jhbuild-maintained because it is a function of marketing, not development. The list of featured applications is maintained on our web properties and has nothing to do with any official module status. -- http://git.gnome.org/browse/jhbuild/commit/?id=12a0bd91 And applications got out of release team scope in the announcement you refer to: 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) -- https://mail.gnome.org/archives/desktop-devel-list/2011-March/msg00045.html But despite that announcement, most of the application module maintainers continued to follow the release schedule, and were part of releases we handled. (as evidenced by http://ftp.gnome.org/pub/GNOME/apps/) Again, the question, what's the meaning of the apps moduleset? It's been the place for a serie of applications handled by the release team, remnants of the old modulesets, but doesn't it lack some more formal definition? If it's applications released by the GNOME project, shouldn't we get back some release criteria? If it's just to facilitate jhbuilding, what's the difference between the -apps and the -world modulesets? So what has changed? I think that there's some confusion here and I'd like to clear it up. As far as I know, everything is just fine: Featured Apps is a marketing function and apps moduleset can include anything to facilitate jhbuilding. Well, there was the moduleset reorg announcement, but after that we also had 8 months of practice, and they don't quite fit, because in some sense, what has changed? nothing, applications still wanted to be under the GNOME shelter, and the release team kept offering that. We put up a feature proposal period in place, and applications kept being proposed, and that discrepancy is part of this thread, Vincent wrote: I said that I didn't feel Boxes should be tracked as a feature. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Boxes (was Re: 3.4 Features, final round)
Zeeshan Ali (Khattak) wrote: On Mon, Nov 7, 2011 at 9:00 AM, Vincent Untz vu...@gnome.org wrote: Le dimanche 06 novembre 2011, à 17:06 +0100, Frederic Peters a écrit : + Boxes https://live.gnome.org/ThreePointThree/Features/Boxes → many commits, mclasen will push the developers to blog a progress report once they have something to show While Boxes look interesting, to me, it feels like it's just an application, and not a feature per se. And I'm not saying that in a negative way :-) You are correct in the sense that it is 'an' application and not 'a' feature. It is more like 2 essential features combined in one: 1. Remote display: It is very common to own/having to deal with multiple machines these days so many users really need ability to easily connect to remote machines (virtual and real). Talking about connecting to remote machines, how will Boxes coexist with Vinagre? Do you expect its features to be available via Boxes by 3.4 time, or should both of them coexist for a while? David, what's your take on this? 2. Trying out OSs: Each time we release GNOME, I really want to try it out and I know many people who do. Same goes for distros but people usually try to avoid risks and therefore most people wait till the OS in question is stable enough. I have even seen people avoid trying out an OS just because they are too scared of it doing any harm to their computers. Users will definitely appreciate an easy and completely secure way to try out OSs. I appreciate Boxes could help here but really, trying out OSs is not a common hobby :) Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
3.4 Features, final round
Hello all, It's about time to decide on the major features we'll track for 3.4. Actually the release team already met yesterday and did a quick round up of the proposed features, here's a summary (title/url) of them as well a a quick release team note. If you feel that something important hasn't been mentioned yet about a proposal, or if you have questions or comments about them, go ahead and speak now. + Zoom options dialog (universal access) https://mail.gnome.org/archives/desktop-devel-list/2011-October/msg00140.html → Some UI details needs to be worked out, but we want that. + Brightness and contrast functionality https://mail.gnome.org/archives/desktop-devel-list/2011-October/msg00141.html → Some techical details needs to be worked out, but want that. + Focus caret/tracking in GNOME Shell https://mail.gnome.org/archives/desktop-devel-list/2011-October/msg00142.html → Still need to be started but there is a good plan. + Braille Translator for Print Documents https://mail.gnome.org/archives/desktop-devel-list/2011-October/msg00143.html → Good thing, we should push dots to #gnome-design for some polish + Information-efficient text-entry interface, driven by natural continuous pointing gestures https://mail.gnome.org/archives/desktop-devel-list/2011-October/msg00144.html → We should bring dasher back to the -tested moduleset, and keep an eye on it, making sure it builds with our platform changes. + Alternative input system based on low-cost webcam https://mail.gnome.org/archives/desktop-devel-list/2011-October/msg00145.html → out at the moment, the feature would need to be integrated to be part of GNOME + Application menu / Actions https://live.gnome.org/ThreePointThree/Features/ApplicationMenu → desrt put out his gio menu model code on a branch, mclasen wrote some gtk test code, mclasen needs to push walters to take a stap at the shell side, hopes to get a prototype by end of November. + Blank slate helps you get started https://live.gnome.org/ThreePointThree/Features/Blank%20slate%20helps%20you%20get%20started → it's getting implemented in gedit, seif has been blogging about it, not sure how it would fit in other applications (we don't have a lot of create document applications). + Boxes https://live.gnome.org/ThreePointThree/Features/Boxes → many commits, mclasen will push the developers to blog a progress report once they have something to show + Help Menus https://live.gnome.org/ThreePointThree/Features/HelpMenus → Shaun has been doing good progress, and reported them recently, still unsure about the way it will fit with app menus (this will probably need a pass in #gnome-design once we have an app menu prototype) but they would be used in other places, so we shouldn't block on this. + IBus/XKB support https://live.gnome.org/ThreePointThree/Features/IBus → many pieces are there, but details remain to be sorted out + Jumplists https://live.gnome.org/ThreePointThree/Features/Jumplists → didn't heard much opinion of it from designers + Network zones https://live.gnome.org/ThreePointThree/Features/NetworkZones → many find the idea useful but all designers hate the idea, mclasen will update the page to reflect that + Lock Screen https://live.gnome.org/ThreePointThree/Features/ScreenLock → Jon has started to put designs on the wiki + System Dialogs https://live.gnome.org/ThreePointThree/Features/SystemDialogs → mclasen will ask stef + a11y themes http://live.gnome.org/Accessibility/ThreePointTwo/NiceToHaves → the feature page needs to be written, the idea seems to be to reuse symbolic icons where possible. + improvements in $foobar → Documents, network panel, user panel, wacom panel Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Attention anyone uploading binaries to ftp.gnome.org/pub/binaries - understand the GPL
Colin Walters wrote: Just a reminder - 2.5 weeks away now. On Wed, 2011-09-21 at 11:10 -0400, Colin Walters wrote: Also, just to move things along, I plan to remove any binary which does not have a corresponding SOURCES file in say one month from now. walters@master:/ftp/pub/GNOME/binaries$ find -name SOURCES ./mac/frogr/0.5/SOURCES ./mac/frogr/0.6/SOURCES ./mac/frogr/0.6.1/SOURCES walters@master:/ftp/pub/GNOME/binaries$ =( You could add /ftp/pub/GNOME/misc/ as a base directory; we do not have the 3.2 live image on there, but while the Promo DVD has a README file with a Getting the Source Code paragraph, we do not have anything for the Fedora based live 3.0 CD. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.3 Schedule Draft
Shaun McCance wrote: On Tue, 2011-09-20 at 14:42 +0200, Andre Klapper wrote: A draft for the GNOME 3.3 schedule is available at https://live.gnome.org/ThreePointThree#Schedule Comments are welcome; Silence means compliance. I notice there's no longer a feature freeze. I was going to propose a change to our UI freeze policy, but my proposal involved feature freeze, and it's gone. Intentional? It's intentional, the release team decides on new features, we'll do this early (week 6), and this cycle we will try to be more active, getting regular status updates on the different features). But this doesn't encompass all developments happening in GNOME, but a set of major user visible (and marketable) changes, typically affecting several modules, in need of some consensus, and a person to lead the change.. For other features we will keep on pushing for people to publish roadmaps, but it's simply not possible to forbid other developments happening. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.3 Schedule Draft
Shaun McCance wrote: The release team decides on big new features that span the desktop. Individual module maintainers still add features as they like. Let's say the Evince developers decided to add support for a new document format. It's not really a UI change in the sense we've traditionally understood, but it is a feature. And it affects the help. Absent a feature freeze, they could add support right up until the hard code freeze, a mere week before the stable release. Of course you're right on this; with the serie of changes from module proposal to feature proposal, I failed to notice that feature freeze did already exist, with a different meaning for feature; this should be fixed, let's have THE freeze discussed in your other thread. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
From here to apps
Hey, New apps are being designed on https://live.gnome.org/Design/Apps/ and it's really nice, we are getting Contacts and Documents on our computers in 3.2. Those days I am wondering about apps that are in domain spaces where we already have good applications, this is prompted by a comment from David Nielsen on the Music page: The design so far looks some what like what Banshee has shipped for a long time for MeeGo and I would suggest using that as a start off point. Upstream already has a solid media management experience that is well deployed and tested. Adoption of GNOME3 technology is ongoing and the design of Banshee allows for easily experimenting with new UIs such as this one. There's Music (and we also have Rhythmbox in that space), but this is for example also the case for Photos (Shotwell?) and Boxes (Vinagre? virt-manager?). Speaking of Vinagre, it even has Implement some of the ideas from GNOME desktop sharing/virtualisation design mockups on its roadmap for 3.4 (see https://live.gnome.org/Vinagre/RoadMap). So, is there anything we could do to get to the new apps faster, accompanying existing apps to their bright future, benefiting from their experiences? Should we encourage specific apps authors to join #gnome-design? What kind of place can we create for existing applications willing to go the GNOME App path? Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Splitting gnome-utils for 3.4
Emmanuele Bassi wrote: Cosimo: the only issue I can think of when splitting up the repo are the translations; currently, everything is translated into the same domain, so we'll need the i18n teams to perform some surgery. we can probably do it during the split (probably at the cost of the history), though. The translations shouldn't be an issue, the .po files will be duplicated in the new modules, with a lot of unnecessary strings, and those will be eliminated automatically in l10n.gnome.org since they won't be in the respective .pot file. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features-oriented releases
Hello Alexandre, We will soon have 3.2 released, and it's quite time to discuss things for 3.4, and as I said previously, while the features focused process is something we really want, the way it happened for 3.2 was suboptimal. Let's work on this, here are some thoughts. My goal for features is to strenghten the position of the release team, it shouldn't just be a list of things put on a wiki page at the beginning of the cycle, we should demand schedules, progress reports, status updates, during the whole cycle, and over cycles, as a feature can span several of them. This will be an important job and we should therefore concentrate on a limited set of features, and here comes an important point, there is a lot of place for features that are coordinated in an ad hoc manner, without the assistance of the release team. Still it is useful for features to be presented and discussed on the desktop-devel list, as the exchanges will be signs of the directions the GNOME project want to take; and this is on that basis that the release team will have its own discussions, and declare support for some of them. What would be in it? I wrote about new requirements the release team would have, but what are the benefits? This is unfortunately hard to tell, ultimately module maintainers are the decision makers, what are the steps the release team could take to help features happen? Fortunately this shouldn't have to be about forcing patches to get in, maintainers will express themselves in the discussion period, and will agree with the direction of the project. (I do not foresee changes, and hopefully maintainers are ok with the current direction). Comments? Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Switch of GNOME tarball compression format: tar.xz only
Vincent Untz wrote: Le dimanche 11 septembre 2011, à 13:41 +0200, Olav Vitters a écrit : If you have concerns, I'd like to hear about it. I've set the reply-to to desktop-devel-list and distributor-list. With a few other (non-gnome) tarballs switching to xz-only, one thing I realized is that python doesn't support that yet: http://bugs.python.org/issue6715 It means that, for my downstream activities, I'll have to update some scripts to work around this missing feature in python. This is also a problem for library-web (library.gnome.org developer. gnome.org). Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Confused about the release
Hi again! Anyway we're late, and I'll ask you for two more days of patience, so that we have the time to meet and give you a proper answer on the practical questions you have; and we will make sure this gets improved in the future. So we had our release team meeting yesterday evening, Shaun wrote: I noticed that we have Contacts, Documents, and Sushi in the apps moduleset. If shipped, all of these are just core parts of the desktop experience, so I want to document them in the desktop help. But I'm wary of doing that for modules in apps. Documents will just be a preview release, it shows the direction, nothing more, nothing less, I don't think it's worth including it in the desktop help for 3.2. On the other hand the features provided by Contacts and Sushi certainly have their place in the help. Apart of those, other new help topics could be colour management, onscreen keyboard, and support for tablets. I hope this answers your question, we are really sorry to provide you this info so late in the cycle, we are still commited to keep going on with the feature focused process, but we will improve the schedule, and the reporting from the release team. And really, don't hesitate to pester us whenever you feel we are acting in a black box. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Confused about the release
Hi Shaun, The lack of module discussions overall is making it difficult for me to keep track of what the docs team needs to work on. I used to be able to send a documentation status report for each module before the decisions were made. Now it just seems like a black box. Sorry about that, it's definitely a change in how we approach the releases and things are far from perfect and still need to be adjusted, for example there have been discussions (remember the feature proposal: backup and how it turned in a external gnome control center panels thread) but they were not systematic, and more importantly, they were not followed by a formal decision by the release team. This is also because there were numerous changes in the release team, and time had to be dedicated to get the new members to know about the technicalities of our release processes, with less time to use on the human/community processes :/ Anyway we're late, and I'll ask you for two more days of patience, so that we have the time to meet and give you a proper answer on the practical questions you have; and we will make sure this gets improved in the future. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: TARBALLS DUE: GNOME 3.1.90 beta release, and freezes
Richard Hughes wrote: On 28 August 2011 08:18, Frederic Peters fpet...@gnome.org wrote: We pushed it back to make it rock, so we count on you to deliver your tarballs on time, this is before Monday 23:59 UTC. Thanks! Monday is a bank holiday in the UK, so I have to work on my day off or will early morning Tuesday be acceptable? I don't mind the former if it's a hard requirement. :-) It's nice to ask, so you'll be granted an exception :) Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Update GnuTLS minimum dependency to 2.12.0?
Hi Stef, In order to complete the GIO TLS Database work [1] for smart cards and other PKCS#11 databases (like gnome-keyring), it looks like I'll need to update the GnuTLS dependency [2] to 2.12.0 or later. Any objections to doing this? Are we too late in the release cycle? It looks really new, from a quick glance at distro websites, it's not available in Fedora 15 nor in Ubuntu 11.10; do you have a patch for jhbuild to build gnutls 2.12, does it work, are other packages using gnutls working with the new version? Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On the Interaction with the design team
Jason D. Clinton wrote: On Wed, Jun 1, 2011 at 11:38, Johannes Schmid j...@jsschmid.de wrote: Pretty good list of examples. All of these projects are mostly driven by Red Hat full-time employees (which isn't a bad thing in general). It happens to be the same company employing big parts of the core design team. While this doesn't mean it is a closed group of people, for an outside developer or volunteer it pretty much feels like that even if the individuals of that group are totally open to external contribution/envolvement. To *who* does it feel that way? If you're going to insinuate that people have tried to get involved and been rebuffed, then I think the responsibility here falls to you to provide an example. Please don't talk around the accusation by inferring that it's some kind of RH conspiracy. It's not. Johannes is definitely a active member of the GNOME community, and in my opinion the work he has been doing to make it possible for new developers to come and use our platform is underestimated (Anjuta, the dev doc tools hackfest, the continued work on platform demos, etc.). Therefore I don't think you should dismiss what he wrote, as if he had just a vague knowledge of our community, mimicking his message as there's a Red Hat conspiracy. And a second point is that it may not be easy to give examples, not because they do not exist but because we may hesitate to bring the involved persons in the discussion without their consent. (I don't know if it's the case for Johannes, it's certainly my case). Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Lennart Poettering wrote: I'd like to propose systemd (GPL2+, http://www.freedesktop.org/wiki/Software/systemd) as blessed external dependency for GNOME 3.2. There actually isn't a module proposal period anymore. We are using feature or design proposals now. But the process for external dependencies was different anyway. Recently I was trying to categorise our 2.x external dependencies, thinking about the way to handle this for 3.x, and came with three levels: ** 1st level ** Established, stable, system modules, they have been in place for a long time, with stable API and ABI, and they exist in sufficient versions in the distributions commonly used by GNOME hackers, even in older but still used versions (Fedora 13 for example). Examples : libxml2, libpng, dbus... Proposed guideline : mentioned as dependencies with a base version, not built by default by jhbuild. Rationale : we want to reduce the number of modules that need to be built to start developing on GNOME. ** 2nd level ** Modules developed outside GNOME, with little attention to our schedule, but with an active development, and where we want to track recent code. Examples : mozilla (js-185 nowadays), poppler. Proposed guideline : built from tarballs, version bumps whenever a module need a new version. Rationale : we need recent code, but we do not want to arrive on a release days with modules failing to build because they require some code only available in $DVCS. ** 3rd level ** Modules developed outside GNOME, with attention to our schedule (i.e. we can ask for a tarball and get it in two days). Examples : webkitgtk, polkit. Proposed guideline : treated like any other GNOME module, built from latest git. Rationale : we do not need to put extra burden on modules that are close to us. At which level would you see systemd integrated, now, and in the future? Also you are speaking about (D-Bus) interfaces, and it is already envisioned to have them implemented by other components, should we talk about D-Bus interfaces that we expect to be available for GNOME, instead of saying systemd? Something else is the ability to run development GNOME, the most common tool those days is jhbuild, which was created way before D-Bus, and it's not always straightforward to get it working with D-Bus services, do you believe it will be possible to have systemd built and useful from jhbuild, or do you expect systemd will have to come from the distribution? Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Shaun McCance wrote: I think that's the idea behind the Apps moduleset, but not Core. Core is the operating system. Apps are some things we think you might like to install on top of it. At least, that's my understanding. That's correct. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Firewall configuration [was Re: no external panels for gnome-control-center]
Bastien Nocera wrote: Feel free to follow the discussions about firewalls on the fedora-desktop list. (...) Shouldn't we try to have an appropriate @gnome.org list to discuss such things (os level), if we consider that *desktop*-devel is not the right venue? (like we #gnome-os on irc) Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Ray Strode wrote: 2) Giving GDM a more of a GNOME 3 look and feel (as per the mockups you already mentioned elsewhere in the thread) The other points are also important, and could certainly be added to the feature page, but this one is explicitely cited (see http://live.gnome.org/ThreePointOne/Features/LoginScreen), it would be great if you completed it. Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dropping generation of old devhelp format in gtk-doc
Stefan Kost wrote: In 2005 we created a new format for devhelp index files that contains more details. It is supported since devhelp-0.11 (18.Dec.2005). The next release of gtk-doc will not generate the old devhelp files anymore. This speeds up the builds a bit and saves some bytes on your hard-dives :) If I am overlooking something here, please let me know. library-web (used to generate developer.gnome.org) was still parsing .devhelp files in some places, I just pushed a fix. Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
Bastien Nocera wrote: Rawhide and will be in Ubuntu Oneiric once we land the GNOME 3 control center. That won't work for long. Once we've move the Bluetooth panel directly in the control-center, we'll be removing the external API from the control-center. It was only added for gnome-bluetooth, and will be removed then as well. It was also envisioned to have a colour management panel; what's the status on this? Is there some kind of guidance given for system settings that are not considered general enough for a settings panel? Straight to the tweak tool? Cheers, Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Orca's external dependencies
Hi Joanmarie, Looking at the 2.91 External Dependencies list [1], I see neither Speech Dispatcher nor OpenTTS. OpenTTS got approved for the prior cycle. [2] But they've since re-merged (unforked?) with Speech Dispatcher. So Do I need to propose Speech Dispatcher as an external dependency needed by Orca, or can I assume that because OpenTTS got blessed, Speech Dispatcher inherits that blessing and simply needs to be added to future lists of dependencies? Similarly, Orca has always depended upon BRLTTY [3] for refreshable braille. Thus I was surprised to discover that BRLTTY was not listed as a dependency. Distros seem to know to include it, but should BRLTTY be something officially made an external dependency of GNOME? Finally, if the answer to my question about BRLTTY is Yes, it should be proposed/considered by the Release Team, then I'd like to toss out one more for consideration: Liblouis. [4] Liblouis provides Orca users with the braille translation tables needed for contracted/grade 2 braille. We are moving away of the idea of approving/rejecting individual modules and considering the features we want in GNOME. In that direction we'd say that whatever is needed for Orca to do its work is ok. Of course this calls for some common sense, to keep some coherence in our stack, but in the specific case of Orca we are not adding liblouis to our development platform, it just happens to be a library that is used to provide Orca users an important feature. But we want to have some guidelines, they are still to be discussed, but the current proposal for modules developed outside of GNOME, and with no consideration for our schedule, to require modules to depend on released versions only. Does this answer your question clearly enough? Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Contributions
Hi Erik, a few days ago I read about the platform-wide feature proposal period of gnome 3.2 and I want to know how can someone using gnome not gnome developer propose something to get included into gnome ? I have some ideas, and I want to discuss those with gnome developers, how do I do that ? The features we are currently tracking are more than mere ideas, but still, if there's any particular idea you have, and you think it makes sense to consider it for GNOME (and if it's not limited to a single module, as you'd better contact the module owners for that), please do tell about it here, on desktop-devel-list. Cheers, Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
David Zeuthen wrote: I would imagine Telepathy/Empathy to use GOA to get the Chat accounts that is configured in GOA (in the above example, it would be Google Talk from zeut...@gmail.com and Facebook Chat for davidz25). I would use an Empathy specific preferences window (not appearing in gnome-control-center I think) to add e.g. my ICQ account. Could you elaborate on this, e.g. why would ICQ and other types of online accounts be deported to a specific preferences window? This is somehow related to the Contacts thread, where it is said we could replace the empathy contact list with the shell; in this scheme there's no place any longer for that specific preferences window, and it makes sense (to me) to have it in the online accounts panel, along others. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
