Re: GNOME HIG: Feedback Wanted
Hey Michael, Thanks for the excellent feedback! I've tried to fix all of these points [1]. Michael Catanzaro wrote: ... > On the header bar page: "Header bars are incompatible with menu bars." > On the menu bar page: "menu bars can still be an appropriate choice, > particularly for applications that already incorporate a header > bar." (So that's a contradiction.) That's weird - obvious mistake. Fixed. > The menu bar page specifies that the menu bar should contain all of the > functionality of the app, so surely items in the app menu should be > duplicated in the menu bar. Is this the intended advice? (It's contrary > to what we've been advised in the past.) Either way, it'd be good to > mention this on the app menu page as well, so that it's more visible. I would consider an application menu to be part of the menu modal that the menu bar belongs to. Added some guidance on that. > In the section on app menus, we really need more guidance on the Quit > menu item. Some apps use Quit to close all windows of the app (which > seems to be intended), some use it to close the current window only (to > prevent the user from accidentally closing windows on other desktops, > which is a real problem with the former approach), and others omit Quit > entirely to avoid the issue. We discussed this in the past but didn't > really come to any conclusion. Agree that there needs to be more specific guidance here. Added something. > On the spinners page, you recommend not using spinners if the range is > limited on both ends. Isn't that a little strict? What about, for > example, the time control in the preferences of GNOME Chess? Yes, agree. (That was copied over from the old HIG, I think.) Updated. > In the section on tabs: "Use tabs that are proportional to the width of > their labels. Don't just set all the tabs to the same width" But > nowadays, tabs actually are all the same width. Dynamic tabs always have equal widths, fixed tabs don't - which is what you're referencing here. I've tried to make it a bit clearer, but let me know if you think it's problematic still. > Also, I'm not sure about the advice at the very bottom of the tabs page. > For example, Epiphany surely needs a new tab button in its header bar, > but I don't think it'd look good to display the tab bar when only one > tab is open. Ah yes. Fixed. > On the toolbars page: "the first few buttons in a browser application > should always include Back, Forward, Stop and Reload, in that order." > That advice seems dated. Good catch! Thanks again, Allan [1] https://git.gnome.org/browse/gnome-devel-docs/commit/?id=33340f4563e996a7b22759c59010243c76977980 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME 3.14 Blocker Report (week 38, what's left.)
Welcome to a last (?) round of "TODO:XXX: FIX ME TIL MONDAY!": == gnome-contacts == Make the search provider work again https://bugzilla.gnome.org/show_bug.cgi?id=736147 Untested patch attached. == gnome-photos == gnome-photos: g_str_hash(): gnome-photos killed by SIGSEGV https://bugzilla.gnome.org/show_bug.cgi?id=735746 Stacktrace available but no further investigation yet. == gnome-software == Core dump due to the assertion failed https://bugzilla.gnome.org/show_bug.cgi?id=736362 Reporter provided more info via log attached. == gnome-tweak-tool == tweak_group_shell_extensions.py:321:_got_info:KeyError: 'version' https://bugzilla.gnome.org/show_bug.cgi?id=730177 Anyone willing to try/comment on the attached 10-line Python patch? Not sure if Tweak Tool's maintainer is still alive... == gnome-weather == gnome-weather leaks information of your saved locations in cleartext when not using the app https://bugzilla.gnome.org/show_bug.cgi?id=734048 Unclear if more work needs to be done here? == mutter == Nautilus window becomes larger every time when opening https://bugzilla.gnome.org/show_bug.cgi?id=733315 Cosimo could reproduce this. ===Three more reports that might be good to fix:=== == adwaita-icon-theme == Spinner has ghosting artifacts (alpha issue with xcursorgen) https://bugzilla.gnome.org/show_bug.cgi?id=734429 == gnome-photos == Would be nice to have a smooth sliding transition between photos https://bugzilla.gnome.org/show_bug.cgi?id=726505 Debarshi: Allan says this should get reverted for 3.14. == gnome-settings-daemon == use IBus 1.5 api when obtain keyboard variant & option. https://bugzilla.gnome.org/show_bug.cgi?id=734980 andre -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.14 Blocker Report (week 38, what's left.)
On Wed, 2014-09-17 at 15:42 +0200, Andre Klapper wrote: > == gnome-settings-daemon == > > use IBus 1.5 api when obtain keyboard variant & option. > https://bugzilla.gnome.org/show_bug.cgi?id=734980 Obsoleted, all that code moved to gnome-shell directly[1]. Yay! [1]: So that the layout switching code can be shared between the Wayland and X.org versions. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
On Wed, 2014-09-17 at 12:02 +0100, Allan Day wrote: > Dynamic tabs always have equal widths, fixed tabs don't - which is > what you're referencing here. I've tried to make it a bit clearer, but > let me know if you think it's problematic still. Looks good! One more question: should we use GtkStack and not GtkNotebook for fixed tabs (since GtkNotebook tabs all have equal width)? Using GtkNotebook in preferences dialogs is a common pattern, for example. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Giving up maintenership of my modules
On Tue, 2014-09-16 at 07:17 +0200, Juan Rafael García Blanco wrote: > Does Gnome keep track of which projects need developers, > documentators, maintainers, ...? I mean something similar to gnu's > savanah. Developers: Always needed. Documentation: e.g. https://wiki.gnome.org/DocumentationProject/Tasks/ApplicationHelp Maintainers: Not that I am aware of. The latter is a problem. What does Savanah exactly do? I'm only aware of Debian pinging maintainers automatically + regularly to confirm they are still around and not "missing in action" / "away without official leave". I wonder what other FOSS projects do. Thanks to Fred we do have https://people.gnome.org/~fpeters/health/ which lists a "code activity score" (bus factor?) for each module - the lower the number, the better. But I assume those numbers don't automatically update and might be a bit dusty now. The question is who and how to turn that into something 'actionable'. As far as I know nobody is 'proactively' reaching out (where?) to maintainers on the leave (=making them realize) and finding potential folks to take over. andre (using words like 'proactive' and 'actionable' that he hates) -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
Michael Catanzaro wrote: ... >> Dynamic tabs always have equal widths, fixed tabs don't - which is >> what you're referencing here. I've tried to make it a bit clearer, but >> let me know if you think it's problematic still. > > Looks good! One more question: should we use GtkStack and not > GtkNotebook for fixed tabs (since GtkNotebook tabs all have equal > width)? Using GtkNotebook in preferences dialogs is a common pattern, > for example. I don't know of a way to do tabs without GtkNotebook right now. We've spoken a fair bit about writing a new tab widget based on GtkStack though, and that's something that I'm hopeful we'll get around to for 3.16. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Giving up maintenership of my modules
On Wed, Sep 17, 2014 at 3:07 PM, Andre Klapper wrote: > On Tue, 2014-09-16 at 07:17 +0200, Juan Rafael García Blanco wrote: >> Does Gnome keep track of which projects need developers, >> documentators, maintainers, ...? I mean something similar to gnu's >> savanah. > > Developers: Always needed. > Documentation: e.g. > https://wiki.gnome.org/DocumentationProject/Tasks/ApplicationHelp > Maintainers: Not that I am aware of. ... > Thanks to Fred we do have https://people.gnome.org/~fpeters/health/ > which lists a "code activity score" (bus factor?) for each module - the > lower the number, the better. But I assume those numbers don't > automatically update and might be a bit dusty now. ... The other side of it is knowing where maintainers are needed, and that requires knowing where the priority bugs are. > The question is who and how to turn that into something 'actionable'. > As far as I know nobody is 'proactively' reaching out (where?) to > maintainers on the leave (=making them realize) and finding potential > folks to take over. ... Seems like something the release team could be doing. It would require that we find the right formula for attracting maintainers, of course. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.14 Blocker Report (week 38, what's left.)
On Wed, Sep 17, 2014 at 03:42:17PM +0200, Andre Klapper wrote: > gnome-photos: g_str_hash(): gnome-photos killed by SIGSEGV > https://bugzilla.gnome.org/show_bug.cgi?id=735746 > Stacktrace available but no further investigation yet. I have attached a fix. I will wait a bit for the Tracker folks to respond. Real life got in the way of our IRC conversation. Cheers, Debarshi -- It has its possibilities but I am bound by my limitations. -- Vivek Shah pgp_WbgCbildA.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Tracker] Proposed future for Tracker - Smaller modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/09/2014 17:11, Martyn Russell wrote: Hi Martyn, >> >> My proposal would be to keep tracker-store, ontology and >> libtracker-sparql together (as one project). > > The reason I didn't put libtracker-sparql with tracker-store / > core things is that logically it's quite a different thing for > applications wanting to JUST run SPARQL queries. Well, nope. They depend on tracker-store either way. Since that's the case, then it's better to make tracker-store an impl. detail of libtracker-sparql > I suppose it doesn't make all that much difference, you still > require the store and other bits for libtracker-sparql to operate > anyway. Precisely. Applications wanting to JUST run SPARQL queries, need tracker-store. Even for reading with direct-access, as tracker-store is the one that assembles meta.db for in case it's not there yet and it needs to be created from initial ontology. > I guess you could go as far as to say that you might want to JUST > use DBus and none of the libtracker-sparql support at all, another > reason for it being separate. The DBus-only non-fd-passing Query APIs on tracker-store are purely for development purposes. Nobody should really use them in production. The only meaningful API on the Resources DBus object is GraphUpdated signal. The Steroids or FD-passing DBus API can be used, but preferably applications always use libtracker-sparql and get the benefits of direct-access mode (process prioritization and no-ipc overhead). >> The reason for that is that the actual goal of libtracker-sparql >> was to provide what libsqlite is for a RDMBS and SQL, but for RDF >> and SPARQL. > > Yea, but libsqlite3 and sqlite are separate packages (actually I am > not sure if they're separate projects at all), but having > tracker-store does not mean you have to use libtracker-sparql. sqlite is a package providing the sqlite shell. That would be equivalent to having a package called tracker that provides just the tracker-sparql tool. All of sqlite is in libsqlite, and you can perfectly use libsqlite without the sqlite package, like how I would like libtracker-sparql to be too (tracker is an embedded db vs. an oracle or mysql or postgresql). >> Without tracker-store, libtracker-sparql can't work. > > It's more the other way round I had in mind, without > libtracker-sparql, tracker-store works. Actually, libtracker-data (the code of tracker-store) is also the direct-access implementation of libtracker-sparql. The tracker-store itself is a bunch of in Vala written D-Bus service wrappers around the same libtracker-data (that is used for libtracker-sparql-direct's implementation) plus an eventloop and checkpointing plus some initialization code and DBus daemonization. That's it, that's what tracker-store is :) Everything is in libtracker-data, which is used by libtracker-sparql >> By splitting the ontologies into a separate project, managed by >> the Nepomuk organization or not, we could someday refactor >> libtracker-sparql to support multiple instances of installed >> ontologies. > > I wouldn't split the ontologies out, the store is no good without > the database and without the schema it's even more useless :) Sure it is. There are already a few companies that are using Tracker with a completely different ontology. The tracker-ivi project comes to mind. Will run on the dashboards of some nice cars. > Besides, all the ontology validation and handling is in the > libraries the store depends on. Not correct. All ontology validation rules are in the ontology's own introspection. The libtracker-data's ontology validation rules are created out of that ontology introspection, and nothing about it is hardcoded in it. Meaning that data/ontologies is completely separate from libtracker-data You could install a complete different data/ontologies, and libtracker-data would just happily crunch that and assembly you a different meta.db with different ontology validation rules. In fact, several embedded-solution companies do this today w. tracker. >> Ideal in that scenario would be that tracker-store becomes an >> impl. detail of libtracker-sparql (it'll manage the instances of >> stores on a on-demand basis). >> >> The only real three reasons of existence of tracker-store are: >> >> - GraphUpdated - The fact that SQLite isn't MVCC and we need WAL >> journaling and checkpointing done by a separate 'writer' process > > Yea, single point of update. But whether it comes as a implementation detail of libtracker-sparql or is a central process of a Desktop session; shouldn't be of concern to whoever links with and uses libtracker-sparql. >> - Providing a ontology > > Not sure I follow you here, the reason for the store is not to > provide an ontology - at least libtracker-data does a lot of that > stuff - I would have to double check this. libtracker-data doesn't provide the ontology, data/ontologies does. The libtracker-data implementat
Re: GNOME Panel maintainers
The classical GNOME mode has a lot of users and fans. Please GNOME leadership be open minded and let the community members who wants to enhance it do their work. GNOME Flashback's successes are GNOME's successes. When people join the bazaar, you don't build a cathedral in a bazaar. On Mon, Sep 8, 2014 at 11:48 AM, Alberts Muktupāvels < alberts.muktupav...@gmail.com> wrote: > Hi, > > On Mon, Sep 8, 2014 at 4:10 PM, Emmanuele Bassi wrote: > >> hi; >> >> On 8 September 2014 12:33, Alberts Muktupāvels >> wrote: >> >> > I need some help and/or suggestion on how to take over gnome-panel >> > maintaining. >> >> that's not how it works. >> >> I strongly suggest you discuss it with him, calmly, and productively, >> in order to amicably solve this issue. >> > > Does not look that it is possible otherwise I would not write this mail. > > >> if nothing happens, you can create a clone of the gnome-panel >> repository somewhere else, and convince others that your work is the >> actual upstream. I'd strongly advise against this solution. >> > > I don't think it would be good solution. > > >> > Philipp does not want that I am taking over maintainership of >> gnome-panel. >> > Problem is that he is not maintaining it and does not want that I do >> it... >> >> after reading the various threads it seems that he has concerns on the >> quality of your contributions; have you tried improving them so that >> his concerns will not be relevant any more? it also seems that he >> rolled back your commits and instead moved them to topic branches for >> ease of review and development. >> > > He is only one who find problems with my contributions. > > Rolled back for what? First master was tested by separate > users/distribution maintainers and it was reported that it works - works > better than last release. At that time it was 3.8.0. > > Rolling back he lost at least one commit which is not available in topic > branches nor in master. For ease of review? There is no one else who is > going to review it. Was not it easier to look at code and if he finds > something bad ask me to fix it rather than rolling back, creating new > branches? > > For example he accepted GtkTable to GtkGrid changes in .ui files by other > dev, but did not accept my commit that do some thing in code. I don't see > any reason for this. Can you name any? > > > He is author of 16 commits. And at least half is not related to any >> fixes, >> > just updating news, version bump, adding himself to maintainers. >> >> release management is a huge part of what "maintainer" means, >> alongside code review, and integration of third party contributions. >> > > I agree on this. But to make new release you need something > new/improved/fixed... Is not that maintainers job too? He is just asking > and mostly waiting until someone else will write patches, will review them. > As I said he is not doing anything. Almost all work in last release is my > work. So if I would not do anything how could he make new release? > > >> > GNOME Panel is part of unofficial GNOME Flashback session (metacity, >> > gnome-panel, gnome-applets). I am already maintaining gnome-applets, >> > metacity. Also I have created new module that is very important part of >> > Flashback session. >> >> Flashback is not really sanctioned by GNOME in any way, so the GNOME >> community can at most suggest ways of solving this issue amicably. >> > > It is not official part of GNOME, but still GNOME. Currently we speak > about gnome-panel and there was time when gnome-panel was part of official > GNOME session. > > What about maintainers that used to maintain gnome-panel while it was > official part? Can not they help? > > Also I asked who approved him as maintainer. Till now he has not > responded. Also I did not find any public discussions about it. So there is > possibility that he simply took over maintaining. > > >> > Mailing list subscribers is on my side. >> >> development and maintainership are not popularity contests. >> > > Of course. It was not meant that way. I tried to say that basically > Philipp is not happy with my work, but everyone else on mailing-list is not > happy with his work. > > For example there was user who reported bug about broken EDS in clock > applet. He just responded that it is working asking to do more testing, he > even wrote that he tested. He was wrong. I found problem, I fixed it, I > sent patches to mailing list. Did he even look at them? No. > > >> ciao, >> Emmanuele. >> >> -- >> http://www.bassi.io >> [@] ebassi [@gmail.com] >> > > > > -- > Alberts Muktupāvels > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > -- Andy Tai, a...@atai.org, Skype: licheng.tai Year 2014 民國103年 自動的精神力是信仰與覺悟 自動的行為力是勞動與技能 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/
Re: [Tracker] Proposed future for Tracker - Smaller modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/09/2014 18:54, Martyn Russell wrote: > On 08/09/14 17:46, Philip Van Hoof wrote: [cut] >> No reason. libtracker-sparql users shouldn't care. > > Off the top of my head: > > 1. To provide a DBus interface (may be a legacy reason, but ...) Only GraphUpdated is of concern here. That should indeed stay and is a difficulty in my idea indeed. The Query and Insert D-Bus DBusMessage based API should at all costs be completely avoided. They are cruelly slow and shouldn't at all be called official API (legacy or not, the legacy is btw from before the 0.8.x release, we've had a major version increment since then). > 2. To provide concurrent connections a way to serialise updates Is an implementation detail of libtracker-sparql > 3. To provide a central and singleton authority to the DB schema That's what I want to change in my utopian idea :) > 4. Because of database locking mechanisms employed by SQLite? Implementation detail of libtracker-sparql > 5. To avoid possible race conditions? Implementation detail .. > The last two could be wrong, its been a while since I had to care > about this stuff :) The list mostly correct. tracker-store exists for the purpose of: - - Initiating the ontology - - Applying ontology changes when detected - - Journalling when enabled (which shouldn't be) - - Providing the Backup and Restore API - - GraphUpdated signal (signals on changes) - - Steroids FD passing D-Bus API - - SQLite WAL checkpointing - - Gathering and returning statistics over D-Bus - - Receiving over Steroids FD passing D-Bus API the from libtracker- sparql rerouted write queries Except for GraphUpdated it has no API that isn't an implementation detail or an internal affair of how libtracker-sparql works. > I'm sure many of those things can be improved these days, but > you're talking about making this decision upon some utopian idea > that is not implemented yet. I am talking about doing this for what > we have *now*. That is fair enough. But changes we make *now* should not conflict with these utopian ideas. So let's not split the project, packages and build files up in such a way that a independent libtracker-sparql with an independent ontology package and project can exist. A libtracker-sparql can exists without an ontology installed: the application that uses libtracker-sparql could provide it all by itself, and libtracker-sparql would still have purpose. Just like how libsqlite doesn't come with a SQL schema, instead the applications using libsqlite provide it. >>> Consider the application that only wants to query and not >>> update the DB - they don't want to depend on all the crap >>> needed for updating the DB, just the raw libtracker-sparql >>> part. >> >> >> Except that they already and always depend on tracker-store. You >> can't avoid it (read libtracker-sparql's initialization code: you >> always and necessarily depend on it). > > I guess it depends on what level you care about "depending" on > something. Hard dependency. Unavoidable. Kind regards, Philip -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJUD3HNAAoJEEP2NSGEz4aDwoQH/15HZMdxABgnpBhd9irSvqSO g8gkp1qkUroQyx5w8gjIo7G6kZfEc9h1EpIqMI5QJjhgL0wJwXhLqzWgfJVyKul7 bTRxYEJQvj2qc/qYt/JijpRYJxm4PWGo1G+FhdKnxMti88+QK2JnwzPNOrO/pX1D 83oInyQwd3t+U6o5zqxQ3VVn0qcLVZWClVPUDHSjVa9BWIEy7tfpzY++xyhYRH3y yhSQE+0hiNgRJLsN1+mjr8ACBOFmWXYKhEh+tCz43uMcggN69QuiBncT2h9nvCF1 0AhyH8Bc1BgjHoZp3XFtX8x7LnNBX3QbTWyEFEjnQdf2/CBgSLDQtRrUm52+vDQ= =ftvw -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: String freeze break request for evolution-data-server (3.12)
2014-09-09 15:06 GMT+02:00 Alexandre Franke :
> On Tue, Sep 9, 2014 at 1:23 PM, David Woodhouse wrote:
>> I'd like to backport some fixes from Evolution master to 3.12 which fix
>> GSSAPI HTTP authentication and error reporting¹.
>>
>> Previously, if we were unable to translate an error number into a string
>> we would end up with an untranslated message of the form 'Unknown error
>> code' or 'Unknown code %d' from libcom_err.
>>
>> Now the code is fixed, we end up handling the lookup failure in EDS, and
>> report it slightly more coherently as
>> _("(Unknown GSSAPI mechanism code: %x)")
>>
>> So we have a new untranslated string... in place of a string which was
>> previously not only untranslated but untranslatable. In a case that
>> should hopefully never happen now that we're actually looking up the
>> error codes the right way, and where the message text wasn't giving the
>> user much information anyway (only the number might *possibly* be
>> helpful.
>>
>> On the whole, I'm not going to lose sleep over it being untranslated :)
>
> 1/2 from i18n.
>
Do I understand correctly that the user can see this string now,
always untranslated? If so, then 2/2 from i18n.
--
Piotr Drąg
http://raven.fedorapeople.org/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Giving up maintenership of my modules
On Mon, Sep 15, 2014 at 1:41 PM, Andre Klapper wrote: > Thanks for announcing because many developers end up AWOL not realizing > and overcommitting while time is precious. > > Wondering if Engagement / Outreach (CCed) has general thoughts on > communicating "modules in need of active maintainership". > > It is possible, we could reach out through social media and maybe reddit/r/gnome or /r/linux. See if people might be interested in taking up maintainership. If you have prospects that you want to tap, that would be the best though. It's really inspiring and wonderful to be recognized and ask to take over a module. sri > The new "stats" tab for modules on https://git.gnome.org/browse might > list some maintainer candidates that could be contacted in such cases? > > On Mon, 2014-09-15 at 09:40 -0700, Giovanni Campagna wrote: > > - gnome-shell-extensions - Florian has been doing regular releases and > > bug fixes for this > > Related, there's also a growing review queue. See > https://bugzilla.gnome.org/show_bug.cgi?id=720636 > > andre > -- > Andre Klapper | ak...@gmx.net > http://blogs.gnome.org/aklapper/ > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Only fallback mode with kernel 3.16
Hi list, I'm currently looking into a weird behavior with GNOME 3 starting in fallback mode every now and then. I only experience this issue with the latest 3.16 kernel, I suspect an issue with my graphics driver. There are no issues using 3.14.18 instead, perhaps there's less video RAM available when running kernel 3.16... To debug, I need to know when, why GNOME starts in fallback mode (using llvmpipe). Debian stable, 32bit, Lenovo T400 GNOME Shell 3.4.2 laptop:~$ grep Mem /var/log/Xorg.0.log [ 8.975] (--) PCI:*(0:0:2:0) 8086:2a42:17aa:20e4 rev 7, Mem @ 0xf440/4194304, 0xd000/268435456, I/O @ 0x1800/8 [ 8.975] (--) PCI: (0:0:2:1) 8086:2a43:17aa:20e4 rev 7, Mem @ 0xf420/1048576 laptop:~$ lspci |grep 02\. 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) Thank you in advance jan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Giving up maintenership of my modules
On Mon, 2014-09-15 at 13:50 -0700, Sriram Ramkrishna wrote: > > > On Mon, Sep 15, 2014 at 1:41 PM, Andre Klapper wrote: > Thanks for announcing because many developers end up AWOL not > realizing > and overcommitting while time is precious. > > Wondering if Engagement / Outreach (CCed) has general thoughts > on > communicating "modules in need of active maintainership". > > > > > It is possible, we could reach out through social media and maybe > reddit/r/gnome or /r/linux. See if people might be interested in > taking up maintainership. If you have prospects that you want to tap, > that would be the best though. It's really inspiring and wonderful to > be recognized and ask to take over a module. I seriously doubt we'll find a new *maintainer* that way. A maintainer needs to be somebody who has a track record of contributions. For example, you might well consider Ross Lagerwall a maintainer of gvfs, or Phillip Wood one for sound-juicer. If you manage to find new developers for those projects, maybe in time they'll rise to become great maintainers... Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
