Re: I want to make a Gnome PC, what integration would you do?
Hi Jason, It's not clear who you are targeting so it's difficult to answer your questions. Do you questions relate to hardware or software features? For what it's worth: as far as I am aware, the only market for PCs preinstalled with linux are people who are new to linux. Assuming that is a fair assumption to have made (and that you're asking about software) then the user might want minimal or they might not, depending on their budget but overall I would imagine that this sort of buyer would most likely go for ease of use and stability above all else (but this is unlikely to be news). Magdalen On Wed, Dec 3, 2014 at 6:54 AM, Jason (spot) Brower encomp...@gmail.com wrote: No not a sales terminal, but a PC, just one model, no options, that would feature gnome and a selected repository of software. Something for users that really enjoy as it is totally built for both the software and hardware. Something small, with modest specs, but because of our selection it would work very well with Gnome. It would be build with a special version of Ubuntu Linux with the Latest gnome, think of it like Ubuntu Minimal with Our special selection and setup on top. Of course the pc would be open and you cna format and do what you like with it. But I just want to sell one model at a time and have a team to help specialize the gnome experience for users. If you had access to a computer like this, what kind of integrations would you imagine making for it? Colors, styles, size, etc... even the slightest feature shouldn't be overlooked. I have access to some powerful hardware manufacturers, and I want to build and send a plan out to the companies and investors to take it further. BR, Jason Brower ___ 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
Commit auto-links in bugzilla comments
Hello, I'd like to ask: how does the auto-links for commits in the new bugzilla work? I mean, if I write something like: commit abcde12345 then the abcde12345 will become a link to the sources in the product the current bug is filled for. It works similarly to bug auto-link references, which is nice. My problem is when one change for a product A requires also a change in product B and I reference commits for both products within one bug report. That may cause one of the commit links invalid. Is there a way to tell the comment parser that the commit itself belongs to another product than the one the bug is filled for? Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: I want to make a Gnome PC, what integration would you do?
On Tue, Dec 2, 2014 at 10:54 PM, Jason (spot) Brower encomp...@gmail.com wrote: Yikes, talking about a late response. I was on vacation, otherwise I would have answered this. No not a sales terminal, but a PC, just one model, no options, that would feature gnome and a selected repository of software. Something for users that really enjoy as it is totally built for both the software and hardware. Something small, with modest specs, but because of our selection it would work very well with Gnome. It would be build with a special version of Ubuntu Linux with the Latest gnome, think of it like Ubuntu Minimal with Our special selection and setup on top. How exciting! If you're talking about something small, do you mean the hardware as well? I would have said go with a NUC (note:I'm an Intel employee, add salt) Small footprint, and decent specs. I'm assuming you're talking about a desktop machine not anything mobile. As for a distro, you could roll your own if you are looking for something light. The vision we want these days is that we want all apps to come from GNOME Software. You probably want to wait till the next version of Ubuntu which I believe will finish the port to QT? (someone from Canonical or Ubuntu want to help me here?) Right now, a lot of things are patched and the experience is not pure GNOME. You could also use one of the Ubuntu re-spins. Of course the pc would be open and you cna format and do what you like with it. But I just want to sell one model at a time and have a team to help specialize the gnome experience for users. Sounds good. If you had access to a computer like this, what kind of integrations would you imagine making for it? Colors, styles, size, etc... even the slightest feature shouldn't be overlooked. I have access to some powerful hardware manufacturers, and I want to build and send a plan out to the companies and investors to take it further. That's a little hard to quantify, especially on this mailing list. Most people do some kind of market research for that kind of thing. If you have that data, then when you do pitch it to hardware manufacturers, you'll have their full support. The hardest part of all of this is of course, making sure you pick manufacturers that are willing to open source/GPL3 their hardware drivers/hardware. If you do get traction, the GNOME Foundation Board of Directors would be interested in how you fare. Please drop them a note at bo...@gnome.org. We would love to see you be successful in your venture. :) Best, sri BR, Jason Brower ___ 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
Re: I want to make a Gnome PC, what integration would you do?
On Mon, Feb 9, 2015 at 9:19 AM, Sriram Ramkrishna s...@ramkrishna.me wrote: On Tue, Dec 2, 2014 at 10:54 PM, Jason (spot) Brower encomp...@gmail.com wrote: One additional postscript. Please subscribe to engagement-l...@gnome.org. This is kind of off topic on desktop-devel which is concerned about GNOME development. The people more interested in what you are doing are on the engagement list and of course the board. sri ___ 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 Mon, 2015-02-09 at 10:57 +, Debarshi Ray wrote: On Mon, Feb 09, 2015 at 10:47:37AM +, Philip Withnall wrote: I guess there are two approaches: making async APIs easier to use; and discouraging use of sync ones. I think the GAsyncResult framework we?ve got is pretty good, and I can?t think of a way to simplify it. One convention that I like is to use a _sync suffix for sync APIs, instead of an _async suffix for async ones, because it lets me spot synchronous calls with grep. A little sad that there are things like g_file_read that are sync, not async. We had a brief discussion about that at the DX hackfest, and I think the consensus was that the current naming scheme (no suffix = sync, ‘_async’ suffix = async) is unfortunate, but has to be kept for consistency reasons. It would be really confusing to switch to a new scheme while keeping the old one. :-( 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
- Original Message - On Mon, Feb 09, 2015 at 10:47:37AM +, Philip Withnall wrote: I guess there are two approaches: making async APIs easier to use; and discouraging use of sync ones. I think the GAsyncResult framework we?ve got is pretty good, and I can?t think of a way to simplify it. One convention that I like is to use a _sync suffix for sync APIs, instead of an _async suffix for async ones, because it lets me spot synchronous calls with grep. A little sad that there are things like g_file_read that are sync, not async. We already have g_file_read_async, it was probably typo, however I wonder which methods doesn't have async versions? Would be probably good start to implemented them if there are any. Regards Ondrej ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Discouraging use of sync APIs
Hi all, From some feedback from real-world users of GLib/GIO (see the ‘Feedback from downstreams’ thread), and just from looking at our own code in GNOME, it seems that people persistently use sync versions of APIs in the main thread when they should be using async ones.* How can we fix this? I guess there are two approaches: making async APIs easier to use; and discouraging use of sync ones. I think the GAsyncResult framework we’ve got is pretty good, and I can’t think of a way to simplify it. (Suggestions welcome.) For discouraging use of sync APIs, I have two strawman ideas: 1. Hide the sync APIs in the documentation index, and only allow their documentation to be viewed from a link from the async versions. That would potentially fix the case where someone searches for ‘file read’, finds g_file_read() as the first result, and never looks as far as g_file_read_async(). 2. A bit more extreme: emit a warning every time a sync API is run in the main thread (but not if it’s run in a worker thread). This should capture precisely the situations we want to avoid (sync calls blocking the main thread’s loop), but is a bit ugly, and people don’t always check their code for runtime warnings. 2b. Similarly, we could potentially statically analyse which threads each sync function could potentially be called from, and warn if sync functions are potentially called from the main thread. But I haven’t put much thought into how such an analysis would work, and it wouldn’t be trivial to implement. What are people’s thoughts? Philip * There are definitely legitimate uses of sync APIs, but not from the main thread, ignoring trivial command line utilities (and even then, if they want to handle signals properly, they should be running a main loop). 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 Mon, Feb 09, 2015 at 10:47:37AM +, Philip Withnall wrote: I guess there are two approaches: making async APIs easier to use; and discouraging use of sync ones. I think the GAsyncResult framework we?ve got is pretty good, and I can?t think of a way to simplify it. One convention that I like is to use a _sync suffix for sync APIs, instead of an _async suffix for async ones, because it lets me spot synchronous calls with grep. A little sad that there are things like g_file_read that are sync, not async. Cheers, Debarshi ___ 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 Mon, Feb 09, 2015 at 12:53:46PM +, Emmanuele Bassi wrote: hi; On 9 February 2015 at 12:40, Debarshi Ray rishi...@lostca.se wrote: On Mon, Feb 09, 2015 at 11:14:46AM +, Philip Withnall wrote: On Mon, 2015-02-09 at 10:57 +, Debarshi Ray wrote: One convention that I like is to use a _sync suffix for sync APIs, instead of an _async suffix for async ones, because it lets me spot synchronous calls with grep. A little sad that there are things like g_file_read that are sync, not async. We had a brief discussion about that at the DX hackfest, and I think the consensus was that the current naming scheme (no suffix = sync, ?_async? suffix = async) is unfortunate, but has to be kept for consistency reasons. It would be really confusing to switch to a new scheme while keeping the old one. :-( There is really no consistency at the moment. eg., see g_dbus_proxy_new and the code generated by gdbus-codegen. It differs from class to class and module to module. there's a pattern, but it's neither communicated nor discernible. the file operations (which are the oldest ones in GIO) follow the default-sync/explicit-async pattern; in general, sync file operations on local storage are not terrible, even after going through a layer of indirection, and the applications dealing with remote storage were a minority when the API was introduced. few applications had to deal with both at the same time ? namely, Nautilus ? and those were already using threads internally, or async callbacks. 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 see. Thanks for clearing that up. Cheers, Debarshi ___ 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 Mon, 2015-02-09 at 13:42 +, Philip Withnall wrote: On Mon, 2015-02-09 at 14:02 +0100, Bastien Nocera wrote: On Mon, 2015-02-09 at 12:53 +, Emmanuele Bassi wrote: snip 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. I wouldn't want that. I can certainly see that as a necessary evil (say on application startup), and would rather it threw an error if that sync call took too long instead. Why can the startup code not use a GMainLoop? Is there some pattern I’ve missed? I thought in all such situations you could still do with a main loop so you could handle Ctrl+C nicely. What's handling Ctrl+C nicely? I can Ctrl+C stuck applications fine in most cases, and I wouldn't want the handling of such a feature to be the main driver behind my API decisions. On startup, you should try to get the maximum amount of work done in the minimum amount of time. In some cases, pre-populating the UI (while blocking the mainloop) is a better idea than seeing jarring effects after the fact, once the UI has been loaded. ___ 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 Mon, Feb 09, 2015 at 06:52:13AM -0500, Ondrej Holy wrote: We already have g_file_read_async, it was probably typo, however I wonder which methods doesn't have async versions? Would be probably good start to implemented them if there are any. I meant that currently: - g_file_read_async is async - g_file_read is sync ... instead of: - g_file_read being async - g_file_read_sync being sync. Cheers, Debarshi ___ 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
Aha, sorry for misunderstanding. You are right, this is sad. Regards Ondrej - Original Message - On Mon, Feb 09, 2015 at 06:52:13AM -0500, Ondrej Holy wrote: We already have g_file_read_async, it was probably typo, however I wonder which methods doesn't have async versions? Would be probably good start to implemented them if there are any. I meant that currently: - g_file_read_async is async - g_file_read is sync ... instead of: - g_file_read being async - g_file_read_sync being sync. Cheers, Debarshi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
I want to make a Gnome PC, what integration would you do?
No not a sales terminal, but a PC, just one model, no options, that would feature gnome and a selected repository of software. Something for users that really enjoy as it is totally built for both the software and hardware. Something small, with modest specs, but because of our selection it would work very well with Gnome. It would be build with a special version of Ubuntu Linux with the Latest gnome, think of it like Ubuntu Minimal with Our special selection and setup on top. Of course the pc would be open and you cna format and do what you like with it. But I just want to sell one model at a time and have a team to help specialize the gnome experience for users. If you had access to a computer like this, what kind of integrations would you imagine making for it? Colors, styles, size, etc... even the slightest feature shouldn't be overlooked. I have access to some powerful hardware manufacturers, and I want to build and send a plan out to the companies and investors to take it further. BR, Jason Brower ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anyone going to be using ConsoleKit for 3.16 ?
Given that it's broken/removed in gnome-shell 3.16 and that there's been no feedback, I don't see the problem. We should have removed the support in concert, instead of different parts of GNOME doing it at different times, but the expectation already is that ConsoleKit support should be a downstream patch for most parts of GNOME. One more isn't going to hurt. That's the reason we reverted: https://git.gnome.org/browse/gnome-shell/commit/?id=a244c1e987502e359c45c0a9bc0012b5bc635553 in 3.14 for OpenBSD (and FreeBSD). -- Antoine ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anyone going to be using ConsoleKit for 3.16 ?
Okay guys, so what I'll do then is take the code out but post a patch to https://bugzilla.gnome.org/show_bug.cgi?id=743940 that adds it back. You guys can ship that with 3.16 and then drop it with 3.18 when LoginKit is integrated into your distros. That's awesome. Thanks a lot. -- Antoine ___ 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 Mon, 2015-02-09 at 14:02 +0100, Bastien Nocera wrote: On Mon, 2015-02-09 at 12:53 +, Emmanuele Bassi wrote: snip 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. I wouldn't want that. I can certainly see that as a necessary evil (say on application startup), and would rather it threw an error if that sync call took too long instead. Why can the startup code not use a GMainLoop? Is there some pattern I’ve missed? I thought in all such situations you could still do with a main loop so you could handle Ctrl+C nicely. 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 Mon, Feb 09, 2015 at 11:14:46AM +, Philip Withnall wrote: On Mon, 2015-02-09 at 10:57 +, Debarshi Ray wrote: One convention that I like is to use a _sync suffix for sync APIs, instead of an _async suffix for async ones, because it lets me spot synchronous calls with grep. A little sad that there are things like g_file_read that are sync, not async. We had a brief discussion about that at the DX hackfest, and I think the consensus was that the current naming scheme (no suffix = sync, ?_async? suffix = async) is unfortunate, but has to be kept for consistency reasons. It would be really confusing to switch to a new scheme while keeping the old one. :-( There is really no consistency at the moment. eg., see g_dbus_proxy_new and the code generated by gdbus-codegen. It differs from class to class and module to module. We can't break API, so atleast for future additions it would be good to use a better convention. Cheers, Debarshi ___ 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
hi; On 9 February 2015 at 12:40, Debarshi Ray rishi...@lostca.se wrote: On Mon, Feb 09, 2015 at 11:14:46AM +, Philip Withnall wrote: On Mon, 2015-02-09 at 10:57 +, Debarshi Ray wrote: One convention that I like is to use a _sync suffix for sync APIs, instead of an _async suffix for async ones, because it lets me spot synchronous calls with grep. A little sad that there are things like g_file_read that are sync, not async. We had a brief discussion about that at the DX hackfest, and I think the consensus was that the current naming scheme (no suffix = sync, ?_async? suffix = async) is unfortunate, but has to be kept for consistency reasons. It would be really confusing to switch to a new scheme while keeping the old one. :-( There is really no consistency at the moment. eg., see g_dbus_proxy_new and the code generated by gdbus-codegen. It differs from class to class and module to module. there's a pattern, but it's neither communicated nor discernible. the file operations (which are the oldest ones in GIO) follow the default-sync/explicit-async pattern; in general, sync file operations on local storage are not terrible, even after going through a layer of indirection, and the applications dealing with remote storage were a minority when the API was introduced. few applications had to deal with both at the same time — namely, Nautilus — and those were already using threads internally, or async callbacks. 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. 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. maybe we could use G_ENABLE_DIAGNOSTIC for this kind of messages; after all, we're already using it for deprecated properties and signals. ciao, Emmanuele. ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ 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 Mon, 2015-02-09 at 12:53 +, Emmanuele Bassi wrote: snip 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. I wouldn't want that. I can certainly see that as a necessary evil (say on application startup), and would rather it threw an error if that sync call took too long instead. maybe we could use G_ENABLE_DIAGNOSTIC for this kind of messages; after all, we're already using it for deprecated properties and signals. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: OUTAGE: bugzilla.gnome.org, 09th February (09:00 CET) - 10th February (22:00 CET)
The upgrade has been finalized and the machine is back to production. A special thank you goes to Andre Klapper and Krzesimir Nowak for their hard work to make this happen. We are also happy to announce Krzesimir has joined the GNOME Bugmasters team and admin status has been granted to him on bugzilla.gnome.org. We are also delighted about the fact today's upgrade has given a new life to the Bugmasters team: new members are joining and more are willing to participate to the team and most of all old members are back on track to provide their valuable feedback and expertise. While we are confident enough testing was made we welcome everyone to submit bugs that may arise at [1]. Have an awesome evening everyone! [1] https://bugzilla.gnome.org/enter_bug.cgi?product=bugzilla.gnome.org 2015-02-04 20:22 GMT+01:00 Andrea Veri a...@gnome.org: Hi, this upcoming monday we'll be performing bugzilla.gnome.org's upgrade to the very latest Bugzilla release, it being 4.4.8. The upgrade time frame has been kept wide enough for us to perform the following operations: 1. Make sure the Bugzilla database is replicated on our MySQLd replica (mainly dumping the DB and restoring it on the replica so they are both in sync. We need all the tables to be on READ LOCK while doing this so the upgrade is a good time for the replication of this database to be restored) 2. Perform the upgrade itself from release 3.4 to release 4.4.8 3. Perform post-upgrade maintenance operations More information about what happened behind the scenes during these months can be found at [1]. As usual keep an eye at [2], we'll make sure to update it with ETAs as things move forward. [1] http://krnowak.blogspot.it/2015/01/gnome-bugzilla-upgrade.html [2] https://status.gnome.org -- Cheers, Andrea Debian Developer, Fedora / EPEL packager, GNOME Infrastructure Team Coordinator, GNOME Foundation Board of Directors Secretary, GNOME Foundation Membership Elections Committee Chairman Homepage: http://www.gnome.org/~av -- Cheers, Andrea Debian Developer, Fedora / EPEL packager, GNOME Infrastructure Team Coordinator, GNOME Foundation Board of Directors Secretary, GNOME Foundation Membership Elections Committee Chairman Homepage: http://www.gnome.org/~av ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing the Severity field value trivial in Bugzilla
On Thu, 2015-02-05 at 02:14 +0100, Andre Klapper wrote: While/after upgrading to Bugzilla 4.4 soon(TM) [1], I would like to get rid of Bugzilla's trivial Severity field value in order to get a slightly shorter list of confusing choices. Done. There are no open tickets with trivial severity anymore, and you cannot set that severity value anymore. Cheers, 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: OUTAGE: bugzilla.gnome.org, 09th February (09:00 CET) - 10th February (22:00 CET)
On Mon, Feb 9, 2015 at 2:45 PM, Andrea Veri a...@gnome.org wrote: The upgrade has been finalized and the machine is back to production. A special thank you goes to Andre Klapper and Krzesimir Nowak for their hard work to make this happen. We are also happy to announce Krzesimir has joined the GNOME Bugmasters team and admin status has been granted to him on bugzilla.gnome.org. We are also delighted about the fact today's upgrade has given a new life to the Bugmasters team: new members are joining and more are willing to participate to the team and most of all old members are back on track to provide their valuable feedback and expertise. While we are confident enough testing was made we welcome everyone to submit bugs that may arise at [1]. Have an awesome evening everyone! I just want to thank everyone on the sysadmin team for this. This has been a long time coming and took quite amount of work due to the fact that we had a specialized bugzilla install. It's times like this is why having an expert sysadmin team is so important. We are _lucky_ to have such awesome ones. I've worked in a lot of environments, and I know what I speak of. Thanks again guys, you guys are the best! Now if we can maybe get someone to change the UI a bit on bugzilla that would be something... sri [1] https://bugzilla.gnome.org/enter_bug.cgi?product=bugzilla.gnome.org 2015-02-04 20:22 GMT+01:00 Andrea Veri a...@gnome.org: Hi, this upcoming monday we'll be performing bugzilla.gnome.org's upgrade to the very latest Bugzilla release, it being 4.4.8. The upgrade time frame has been kept wide enough for us to perform the following operations: 1. Make sure the Bugzilla database is replicated on our MySQLd replica (mainly dumping the DB and restoring it on the replica so they are both in sync. We need all the tables to be on READ LOCK while doing this so the upgrade is a good time for the replication of this database to be restored) 2. Perform the upgrade itself from release 3.4 to release 4.4.8 3. Perform post-upgrade maintenance operations More information about what happened behind the scenes during these months can be found at [1]. As usual keep an eye at [2], we'll make sure to update it with ETAs as things move forward. [1] http://krnowak.blogspot.it/2015/01/gnome-bugzilla-upgrade.html [2] https://status.gnome.org -- Cheers, Andrea Debian Developer, Fedora / EPEL packager, GNOME Infrastructure Team Coordinator, GNOME Foundation Board of Directors Secretary, GNOME Foundation Membership Elections Committee Chairman Homepage: http://www.gnome.org/~av -- Cheers, Andrea Debian Developer, Fedora / EPEL packager, GNOME Infrastructure Team Coordinator, GNOME Foundation Board of Directors Secretary, GNOME Foundation Membership Elections Committee Chairman Homepage: http://www.gnome.org/~av ___ foundation-list mailing list foundation-l...@gnome.org https://mail.gnome.org/mailman/listinfo/foundation-list ___ 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 Mon, 2015-02-09 at 12:53 +, Emmanuele Bassi wrote: 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. maybe we could use G_ENABLE_DIAGNOSTIC for this kind of messages; after all, we're already using it for deprecated properties and signals. Having that kind of diagnostic (i.e. a developers-only tool) would be nice. Paired with Bastien's suggestion: and would rather it threw an error if that sync call took too long instead. Didn't we have something like that for GTK+'s frame clock? I guess it boils down to really looking at where and why those sync calls are happening. For example: * I turn on my machine and start my session. Gnome-shell brings up an empty desktop. I *can't do anything* until I pop up the Activities, but when I do that, gnome-shell takes a little to read all the icons or .desktop files for the applications, and there is a noticeable delay. At startup, it could read those asynchronously so that they would be ready when I bring up the Activities for the first time. * Gnome-shell takes noticeably longer to respond at startup if the VPN is not started yet *and* my /etc/resolv.conf was left with a DNS server that is only accessible through the VPN. I don't know if gnome-shell actually needs to resolve a host name, or if it's waiting for NetworkManager for something, or what. The first case is about making the best use of time; the second one is probably just a bug, or a bad API that forces gnome-shell to wait. I don't think you can just say, sync calls bad all the time :) Federico -- GPG fingerprint - RSA 4096: 263F 590F 7E0F E1CB 3EA2 74B0 1676 37EB 6FB8 DCCE ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
