On 11/02/15 12:28, Michael Hill wrote:
> On Tue, Feb 10, 2015, at 01:00 PM, 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 res
On Tue, Feb 10, 2015, at 01:00 PM, 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.
>
> jhbui
On Tue, Feb 10, 2015 at 1:06 PM, Allan Day wrote:
> 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/GnomeLo
On 10/02/2015, Frederic Peters wrote:
> 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 o
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 imp
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/Jhbuil
On 10/02/2015, Sriram Ramkrishna wrote:
> Problem: we have many pages on jhbuild documentation
>
> We want to eliminate all of this and have
>
> https://wiki.gnome.org/GnomeLove/BuildGnome
>
> There seems to be some objections to removing some of the more
> in-depth jhbuild documentation. I think
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.gnom
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
In particular, we should identify material from the HowDoI/Jhbuild page
(which conflicts with the guidance on the BuildGnome page) that we want
to keep, and merge it into the BuildGnome page. We should not have
competing pages with competing advice; it's way too confusing for
newcomers.
___
Problem: we have many pages on jhbuild documentation
We want to eliminate all of this and have
https://wiki.gnome.org/GnomeLove/BuildGnome
There seems to be some objections to removing some of the more
in-depth jhbuild documentation. I think overall this is a little
confusing, they are also unm
One quick example: calling g_file_read_async on a GResourceFile spawns a
new thread and does a synchronous stream read from a block already in
memory.
It should just be a single g_bytes_ref, but we have three different classes
created, a thread spawned, and a large amount of locks to do the equiva
Right now the way g_file_read_async works is by scheduling a task on a
worker thread, having the worker thread do the async read, and then
returning a result.
As such, it's impossible to have two async reads done at the same time,
which is really unfortunate from my understanding. If I'm reading a
On Mon, 2015-02-02 at 12:19 +0100, Olav Vitters wrote:
> On Mon, Feb 02, 2015 at 08:05:00AM +, Philip Withnall wrote:
> > It was suggested that I send the presentation to DDL, since it might be
> > of general interest. I haven’t modified it from the hackfest version, so
> > please let me know i
On Tue, 10.02.15 13:59, Philip Withnall (phi...@tecnocode.co.uk) wrote:
> > I am pretty sure if you do async IO like gio does for every single
> > file access you'll just complicate your program and make it
> > substantially slower. For small files normal, synchronous disk access
> > is a ton fast
On Tue, 2015-02-10 at 11:20 +0100, Lennart Poettering wrote:
> On Mon, 09.02.15 10:47, Philip Withnall (phi...@tecnocode.co.uk) wrote:
>
> > 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
On Mon, 2015-02-09 at 14:55 +0100, Bastien Nocera wrote:
> 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:
> > >
> > > > I do agree with Philip's proposal of warni
For anyone who might be interested: git-bz stopped working for me with
the upgrade. However, I was pointed to the following branch, which
does work:
http://cgit.collabora.com/git/user/pwith/git-bz.git/tree/git-bz?h=bugzilla-4.4
Allan
___
desktop-devel-l
On Tue, 2015-02-10 at 10:20 +0100, Alexandre Franke wrote:
> First of all, I'd like to point that the bug report for this feature
> is still open at https://bugzilla.gnome.org/show_bug.cgi?id=559537
>
> We started discussing the "commit in another product" issue there,
> so maybe we can continue
Sriram Ramkrishna 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.
...
>
> I just want to thank everyone on the sysadmin team for this.
Same here! Huge thank
On Mon, 09.02.15 10:47, Philip Withnall (phi...@tecnocode.co.uk) wrote:
> 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
On Tue, Feb 10, 2015 at 9:56 AM, Olav Vitters wrote:
> On Tue, Feb 10, 2015 at 08:38:39AM +0100, Milan Crha wrote:
>> 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?
>
> I could add support for something like:
> m
On Tue, Feb 10, 2015 at 09:58:49AM +0100, Alexandre Franke wrote:
> As I already told Sri on IRC yesterday, if anything is wrong with our
> current bugzilla, you should start by filing bugs. Then we can start
> looking for solutions and someone to implement them. Otherwise we
> can't guess what you
On Tue, Feb 10, 2015 at 9:29 AM, Oliver Propst wrote:
> On Mon, Feb 9, 2015 at 11:50 PM, Sriram Ramkrishna wrote:
>> 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 bugzill
On Tue, Feb 10, 2015 at 08:38:39AM +0100, Milan Crha wrote:
> 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?
I could add support for something like:
module $FOO commit $BAR
Just as now you can do:
comment 13
25 matches
Mail list logo