Re: Planning to deprecate libgsystem, introduce libgsystem2 as git submodule
On Fri, Feb 13, 2015, at 02:51 AM, Dimstar / Dominique Leuenberger wrote:
Would the plan be for gnome-shell to also move to libgsystem2 then (Not
that it makes a lot of use; that could likely be changed easily).
let GSystem = imports.gi.GSystem;
GSystem.log_structured_print('GNOME Shell started at ' +
_startDate,
['MESSAGE_ID=' +
GNOMESHELL_STARTED_MESSAGE_ID]);
Ah yes, introspectable[1] bindings to systemd are something not
covered by this plan so far.
I think the best thing is for it to move to GLib. Something like
g_log_structured(). I filed:
https://bugzilla.gnome.org/show_bug.cgi?id=744456
[1] Accessible to JS/Vala/etc; systemd has its own hand-maintained
Python bindings for a subset of its public API
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning to deprecate libgsystem, introduce libgsystem2 as git submodule
On Fri, Feb 13, 2015, at 02:51 AM, Dimstar / Dominique Leuenberger wrote:
let GSystem = imports.gi.GSystem;
GSystem.log_structured_print('GNOME Shell started at ' +
_startDate,
['MESSAGE_ID=' +
GNOMESHELL_STARTED_MESSAGE_ID]);
I filed
https://bugzilla.gnome.org/show_bug.cgi?id=744457
for this, thanks for pointing it out.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Discouraging use of sync APIs
On Thu, 2015-02-12 at 12:55 -0800, Philip Chimento wrote: On Thu, Feb 12, 2015 at 5:22 AM, Philip Withnall phi...@tecnocode.co.uk wrote: On Thu, 2015-02-12 at 11:22 +0100, Alexander Larsson wrote: On ons, 2015-02-11 at 12:17 +, Philip Withnall wrote: I understand where you’re coming from; we should not be irritating experienced developers. I completely agree. What do you think of the proposal to use sync gstdio.h for small/local/pseudo-file-system I/O and async GIO for all other I/O? I don't think this is a great alternative in many cases. The gstdio stuff may work fine from C, but the GObjects etc of gio makes such use much nicer from language bindings. True. Wouldn’t the languages typically have their own native gstdio-like functions for local file I/O though, which would tend to be integrated nicely? Javascript doesn't; one of the main reasons behind the decision to make JS the first-class citizen for new Gnome apps developers was precisely that it didn't already have its own platform. I got the impression that using, for example, Python's native local file I/O facilities in the Gnome stack was to be discouraged. Bother, good point. Scrap that idea then. In summary, options we’ve discussed so far are: 1. Use gstdio.h for small reads, GIO async for others: - gstdio.h is rubbish from bindings 2. Warn if sync API is used from the main context, enabling the warning on G_ENABLE_DIAGNOSTIC, and only warning if the call takes too long: + Helps in tracking down bugs at the source (rather than just ‘GTK+ is being blocked too long’) + Shouldn’t have any false positives in the cases discussed so far (small reads from console programs, application startup) - Requires active effort to enable (G_ENABLE_DIAGNOSTICS), limiting its uptake 3. Rearranging the docs to promote async functions more ? Has not been discussed - Big red warnings in the docs may just be ignored by people Seems like option #2 is worth going ahead with. I’ve filed: https://bugzilla.gnome.org/show_bug.cgi?id=744458 Anybody have any thoughts about option #3? I’m wary about filling the docs up with big red warnings. Philip 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: Discouraging use of sync APIs
On Wed, Feb 11, 2015, at 02:33 PM, Jim Nelson wrote: One of Philip's earlier suggestions was to print a console warning if a sync call is used. That seems like overkill to me, but it does lead to another possibility. Technically the issue is long synchronous calls blocking the event loop, but in practice the problem is GTK+'s events being starved. Perhaps a more feasible solution would be to issue a console warning when a paint or resize event sits on the event loop for too long. Agree with this. Also, this kind of warning should really only occur after the first paint. Or we could *try* changing it to happen only after the first main context iteration, but I suspect that would still be too annoying. Changing glib to spew errors for sync IO unconditionally during app startup or hiding the sync API docs are just an obviously, totally ridiculous nonstarters - particularly console apps. How is it even a topic of discussion? Not to mention of course that there's unavoidable synchronous disk IO before GLib is already loaded, in the kernel and dynamic linker. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Discouraging use of sync APIs
On Fri, 2015-02-13 at 04:52 -0500, Colin Walters wrote: On Wed, Feb 11, 2015, at 02:33 PM, Jim Nelson wrote: One of Philip's earlier suggestions was to print a console warning if a sync call is used. That seems like overkill to me, but it does lead to another possibility. Technically the issue is long synchronous calls blocking the event loop, but in practice the problem is GTK+'s events being starved. Perhaps a more feasible solution would be to issue a console warning when a paint or resize event sits on the event loop for too long. Agree with this. Also, this kind of warning should really only occur after the first paint. Or we could *try* changing it to happen only after the first main context iteration, but I suspect that would still be too annoying. Only warning after the first main context iteration would allow things like: g_file_read() /* sync startup call to load config */ … gtk_main() Changing glib to spew errors for sync IO unconditionally during app startup or hiding the sync API docs are just an obviously, totally ridiculous nonstarters - particularly console apps. How is it even a topic of discussion? The suggestion has since been refined to be conditional on the I/O taking ‘a while’, being in the main thread, and G_ENABLE_DIAGNOSTICS being enabled. See: https://bugzilla.gnome.org/show_bug.cgi?id=744458 It was originally a strawman idea, precisely for the reason of gauging how ridiculous people thought it was. The idea of unconditional warnings is ridiculous. Not to mention of course that there's unavoidable synchronous disk IO before GLib is already loaded, in the kernel and dynamic linker. But that doesn’t block the main loop, so isn’t causing interactivity problems and we don’t care. Philip 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: Discouraging use of sync APIs
On Fri, Feb 13, 2015 at 09:33:24AM +, Philip Withnall wrote: 3. Rearranging the docs to promote async functions more ? Has not been discussed - Big red warnings in the docs may just be ignored by people Anybody have any thoughts about option #3? I’m wary about filling the docs up with big red warnings. Instead of a warning for each sync function, there could be a longer explanation in the GFile class description: https://developer.gnome.org/gio/stable/GFile.html#GFile.description And/or in the GIO overview (Writing GIO applications): https://developer.gnome.org/gio/stable/ch02.html The latter could contain the longer explanation. And the former could have a reminder with a link to the latter. Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Killing off UNCONFIRMED in Bugzilla
With Bugzilla 4.4 we can disable UNCONFIRMED on a per-product basis. With that option available, I suggest to kill off the UNCONFIRMED status for all products except whomever wants it. I think we had this discussion before, but couldn't easily find that. Reasoning to kill unconfirmed: Unconfirmed at various times gives the impression the bug will not be looked at. Not having this state would solve that. Action required: IF YOU WANT TO KEEP UNCONFIRMED FOR YOUR PRODUCT PLEASE SPEAK UP!! Steps (for all products except the ones opting out): - Change use unconfirmed to false (product specific setting) - Mass change all unconfirmed bugs to new for all Timeline: I want to do this Friday 27 February 2015. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing off UNCONFIRMED in Bugzilla
Hi, On Fri, Feb 13, 2015 at 4:51 PM, Olav Vitters o...@vitters.nl wrote: Reasoning to kill unconfirmed: Unconfirmed at various times gives the impression the bug will not be looked at. Not having this state would solve that. Action required: IF YOU WANT TO KEEP UNCONFIRMED FOR YOUR PRODUCT PLEASE SPEAK UP!! Please keep it for gnome-music at least - we use this status to properly track issues, which might be caused by other projects. We UNCONFIRMED as 'untriaged' and/or 'potentially unclear'. Thanks, Vadim ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing off UNCONFIRMED in Bugzilla
On Fri, Feb 13, 2015 at 9:51 AM, Olav Vitters o...@vitters.nl wrote: With Bugzilla 4.4 we can disable UNCONFIRMED on a per-product basis. With that option available, I suggest to kill off the UNCONFIRMED status for all products except whomever wants it. This would be highly desirable. Bonus points if you do it without sending emails for each bug. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing off UNCONFIRMED in Bugzilla
On Fri, Feb 13, 2015 at 06:39:29PM +0100, Rick Opper wrote: OK... So they just stay new then... I'm not sure that would give the original reporter the impression that something is being done, but as long as the bugs do get confirmed, sorted, whatever then any simplification may be helpful... Things will be done no matter which status it is for the majority of the products. Some products are not maintained at all anymore, for those the status still won't make much difference. The separate step might make sense in case you had a big bugsquad team looking at all the incoming bugs. We don't. The unconfirmed vs new status has little or no meaning. Loads of bugs actually go from unconfirmed to new. I tend to only mark it as new if there's a bunch of people on it and because some people don't understand that if I disagree with the bug, I would've already marked it WONTFIX. If people want to look at bugs they want to triage, there's already bugs filed in the last 7 days. Further, bugs without a response. In the current state, unconfirmed is not going to help you much. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing off UNCONFIRMED in Bugzilla
On Fri, 2015-02-13 at 18:39 +0100, Rick Opper wrote: OK... So they just stay new then... I'm not sure that would give the original reporter the impression that something is being done, but as long as the bugs do get confirmed, sorted, whatever then any simplification may be helpful... OTOH, some reporters or users get frustrated when products keep the UNCONFIRMED status, in spite that those bugs have plenty of comments, even from the product developers. I personally confirm bugs, but it does not mean I am going through hundreds of all bugs with undecided status, which does not mean I do not know what it is going on there. -- Germán Poo-Caamaño http://calcifer.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing off UNCONFIRMED in Bugzilla
On Fri, 2015-02-13 at 18:15 +0100, Rick Opper wrote: Then how will project devs know if a bug is - as the status implies - not yet confirmed? It may be a problem with a single users unique setup, Which is still a bug, and it's still new. or a design decision RESOLVED WONTFIX , or caused by something specific to a certain distribution... RESOLVED NOTGNOME Isn't that the point of this tag? There are other statuses available which already cover those cases. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing off UNCONFIRMED in Bugzilla
On Fri, Feb 13, 2015 at 06:20:15PM +0100, Bastien Nocera wrote: On Fri, 2015-02-13 at 18:15 +0100, Rick Opper wrote: Then how will project devs know if a bug is - as the status implies - not yet confirmed? It may be a problem with a single users unique setup, Which is still a bug, and it's still new. or a design decision RESOLVED WONTFIX , or caused by something specific to a certain distribution... RESOLVED NOTGNOME Isn't that the point of this tag? There are other statuses available which already cover those cases. It's useful to distinguish UNCONFIRMED and NEW. Some products in gnome have many hundreds bugs, and triaging all of them takes a lot of time. What you suggest needs to triage _all_ the bugs. For example in gedit UNCONFIRMED means that the bug is not triaged. With NEW, you're sure that the bug exists (or existed) and should be fixed upstream. For someone willing to contribute, searching in more than 400 bugs is not really convenient. So by filtering the search results to include only the confirmed/NEW bugs, it's already much better (it's what is advised for newcomers on the gedit wiki). Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing off UNCONFIRMED in Bugzilla
Then how will project devs know if a bug is - as the status implies - not yet confirmed? It may be a problem with a single users unique setup, or a design decision, or caused by something specific to a certain distribution... Isn't that the point of this tag? On February 13, 2015 4:51:58 PM CET, Olav Vitters o...@vitters.nl wrote: With Bugzilla 4.4 we can disable UNCONFIRMED on a per-product basis. With that option available, I suggest to kill off the UNCONFIRMED status for all products except whomever wants it. I think we had this discussion before, but couldn't easily find that. Reasoning to kill unconfirmed: Unconfirmed at various times gives the impression the bug will not be looked at. Not having this state would solve that. Action required: IF YOU WANT TO KEEP UNCONFIRMED FOR YOUR PRODUCT PLEASE SPEAK UP!! Steps (for all products except the ones opting out): - Change use unconfirmed to false (product specific setting) - Mass change all unconfirmed bugs to new for all Timeline: I want to do this Friday 27 February 2015. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing off UNCONFIRMED in Bugzilla
OK... So they just stay new then... I'm not sure that would give the original reporter the impression that something is being done, but as long as the bugs do get confirmed, sorted, whatever then any simplification may be helpful... On February 13, 2015 6:20:15 PM CET, Bastien Nocera had...@hadess.net wrote: On Fri, 2015-02-13 at 18:15 +0100, Rick Opper wrote: Then how will project devs know if a bug is - as the status implies - not yet confirmed? It may be a problem with a single users unique setup, Which is still a bug, and it's still new. or a design decision RESOLVED WONTFIX , or caused by something specific to a certain distribution... RESOLVED NOTGNOME Isn't that the point of this tag? There are other statuses available which already cover those cases. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing off UNCONFIRMED in Bugzilla
On Fri, 2015-02-13 at 18:15 +0100, Rick Opper wrote: Then how will project devs know if a bug is - as the status implies - not yet confirmed? 1) Not all devs care about this. Those who care can keep the UNCONFIRMED status. That's what this thread is about, more or less. 2) Not everybody sees a need to query open bug reports based on status. For some, an I can reproduce this comment in the ticket might be sufficient, instead of expressing that via some ticket status. 3) If the person looking at tickets is a developer, s/he might reproduce the bug and fix it in the same step anyway. No need to spend time setting some status which might be workflow overhead. 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: Killing off UNCONFIRMED in Bugzilla
Hi: I would like to keep it for both Contacts (gnome-contacts) and Calendar (gnome-calendar). I've been trying to follow this bug triage guidelines [1], and for me it means bugs I haven't even look at. Once I look at a bug, I move it into NEW, but it serves organizational purposes. [1]: https://wiki.gnome.org/AllanDay/BugManagement ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing off UNCONFIRMED in Bugzilla
On Fri, Feb 13, 2015 at 4:51 PM, Olav Vitters o...@vitters.nl wrote: Action required: IF YOU WANT TO KEEP UNCONFIRMED FOR YOUR PRODUCT PLEASE SPEAK UP!! Please keep it for planner. BTW since 4.0 the new default workflow in bugzilla starts with UNCONFIRMED → CONFIRMED. This can be useful for those that keep UNCONFIRMED because sometimes reporters misinterpret NEW as not touched yet. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing off UNCONFIRMED in Bugzilla
On Fri, 2015-02-13 at 18:43 +0100, Sébastien Wilmet wrote: On Fri, Feb 13, 2015 at 06:20:15PM +0100, Bastien Nocera wrote: On Fri, 2015-02-13 at 18:15 +0100, Rick Opper wrote: Then how will project devs know if a bug is - as the status implies - not yet confirmed? It may be a problem with a single users unique setup, Which is still a bug, and it's still new. or a design decision RESOLVED WONTFIX , or caused by something specific to a certain distribution... RESOLVED NOTGNOME Isn't that the point of this tag? There are other statuses available which already cover those cases. It's useful to distinguish UNCONFIRMED and NEW. Some products in gnome have many hundreds bugs, and triaging all of them takes a lot of time. What you suggest needs to triage _all_ the bugs. For example in gedit UNCONFIRMED means that the bug is not triaged. With NEW, you're sure that the bug exists (or existed) and should be fixed upstream. For someone willing to contribute, searching in more than 400 bugs is not really convenient. So by filtering the search results to include only the confirmed/NEW bugs, it's already much better (it's what is advised for newcomers on the gedit wiki). Then opt-out. I can tell you that UNCONFIRMED isn't used in, at least, gnome-shell, gnome-settings-daemon, gsettings-desktop-schemas, gnome-control-center, totem, totem-pl-parser, gnome-desktop, gom, grilo, or grilo-plugins. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Canonical jhbuild documentation
Hello (sorry for the delay, there were some problems with the email) A little of history of the latest wiki jhbuild pages: When I created the series of BuildGnome CodeContributionWorkflow my intention was creating a simple straightforward workflow for contributing to Gnome for newcommers to Gnome and/or FOSS. So the simpler the better. When I started contributing Gnome 2 years ago I was overwhelmed with the quantity of text I had to read and all the things that I have to took into account (if I have a jhbuilrc previously, if I have ./bin already in my bashrc, etc.) and things that I had to understand (where jhbuild install itself, the jhbuildrc configuration file etc.). I just wanted to get started ASAP to start getting excited. With BuildGnome I merged some of the obsoletes guides. iirc I deleted 5 wiki pages of jhbuild at that time. In the effort to merge all the guides I talked with the authors of those pages and tried to get some feedback with BuildGnome from them and other people inside Gnome and outside. Seems some people inside Gnome were keen of deleting JhbuildIntroduction. So I just let it there. But we should definitely delete it now, it no longer adds anything to the game. Then a few weeks after creating BuildGnome and CodeContributionWorkflow someone (Ryan right?) created HowDoI/Jhbuild (because he didn't know they were already tutorials of Jhbuild in the wiki), which is a very well explained and large guide about jhbuild basics and covers all cases i.e. someone who already could have some jhbuildrc in some folder. But that vision goes against my intention for newcomers. i.e. they don't have a jhbuildrc. BuildGnome it is not a generic jhbuild guide, it's a guide for get started asap in Gnome which uses jhbuild to build and run Gnome applications. That's it. I don't think a newcomer needs more. Then, I didn't want to modify Jhbuild oficial documentation because Jhbuild can be very generic tool, and those users were not my target. But if we agree that Jhbuild is just used only for contributing Gnome, then we could merge some simple guide as the official documentation. In conclusion, I would like to have something as the official documentation/quickstart like BuildGnome with an advanced stuff link for those who wants more. Probably after a few patches they get a git account, and then they want a jhbuildrc, to have their account. But at that point they wont be scared that much with the documentation, and at least they already got started without too much frustration. I already spent time in newcomers and wikis, since it's a priority for me since I started contributing to Gnome, so I don't mind expending more and get it done better if we agree on something. On the other hand, I'm looking forward to have xdg-app and no longer need Jhbuild for this =) Cheers, Carlos Soriano ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing off UNCONFIRMED in Bugzilla
On Fri, Feb 13, 2015 at 04:51:58PM +0100, Olav Vitters wrote: Action required: IF YOU WANT TO KEEP UNCONFIRMED FOR YOUR PRODUCT PLEASE SPEAK UP!! I'm keeping track of opt-outs at https://wiki.gnome.org/BugzillaMaintainers/NoUnconfirmed Feel free to edit, though would appreciate a comment why you opt out. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Discouraging use of sync APIs
On 09/02/15 12:53, Emmanuele Bassi wrote: hi; Hi, :) whne GDBus was introduced, as its primary author, David made the executive decision to follow the default-async/explicit-sync pattern because most of the applications dealing with DBus for IPC were GUI applications using asynchronous API to avoid blocking the main loop. not many people were using DBus in threads, because neither dbus-glib nor any other wrapper around it was thread safe. the existing code base was already used to callback-heavy approaches. I thought at the time GIO started this convention for file operations that sync APIs should be second class citizens to async APIs (i.e. the reverse for how it is currently). Saying that, perhaps that doesn't suit the lower level APIs so well. The other reason is that GLib is quite heavily related to GTK+ and people should be encouraged (i.e. stubs should be async first) to use a core API that fits better with a UI that can not afford to block on I/O. I've also personally preferred to avoid threading unless necessary. it's unfortunate that both GFile and GDBus share the same namespace, thus making the API look inconsistent. both approaches have their own downsides; using threads to perform long running synchronous operations is not at all bad these days, thanks to GTask. it's actually much easier to spawn a GTask and deal with I/O (both file operations and IPC) synchronously, instead of tracking the state over a ton of callbacks. personally, that's how I've been writing I/O heavy code for the past couple of years, as it makes my code much more maintainable. I do agree with Philip's proposal of warning if the sync API is called inside the default main context, even if there's the obvious issue of console-only code that still uses a main loop, but does not have interactivity issues. Yes, Android has something like this, which is quite sensible and would save users from disappointment from time to time I suspect. -- Regards, Martyn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
