Hi!
Should I hold off a large patch to atk, gio2, glib2, gtk2, and pango
until glib2 1.0.4 has been released?
The patch fixes a lot of array conversions that may leak memory.
Hi,
In [email protected]
“[ruby-gnome2-devel-en] Should I hold off a large patch until glib2
1.0.4 has been released?” on Mon, 19 Sep 2011 14:58:50 +0200,
Nikolai W. [email protected] wrote:
Should I hold off a large patch to atk, gio2, glib2, gtk2, and pango
until glib2 1.0.4 has been released?The patch fixes a lot of array conversions that may leak memory.
You can commit the patch if any more critical bug reports
for 1.0.3 in this week. But could you split your large patch
to small patches (because I can’t review a large patch…)
and write user visible changes to NEWS file (because I
don’t want to need many works for collecting changes at the
release time…)?
Thanks,
kou
On Mon, Sep 19, 2011 at 15:18, Kouhei S. [email protected] wrote:
Nikolai W. [email protected] wrote:
Should I hold off a large patch to atk, gio2, glib2, gtk2, and pango
until glib2 1.0.4 has been released?The patch fixes a lot of array conversions that may leak memory.
You can commit the patch if any more critical bug reports
for 1.0.3 in this week.
Sorry, but I don’t understand what you mean.
But could you split your large patch
to small patches (because I can’t review a large patch…)
Well, it’s kind of hard to do so, especially with Subversion.
I could split it across the various sub-projects, I suppose (atk, glib2,
…).
I’ll attach the patch and you can decide if/how I should apply it.
and write user visible changes to NEWS file (because I
don’t want to need many works for collecting changes at the
release time…)?
OK, I’ll mention the new macros (not yet included in the attached
patch).
Please note that there are more of these problems in many of the
libraries. I need to go through all g_new and ALLOC_N calls as well.
Hi,
In [email protected]
“Re: [ruby-gnome2-devel-en] Should I hold off a large patch until
glib2 1.0.4 has been released?” on Mon, 19 Sep 2011 15:44:20 +0200,
Nikolai W. [email protected] wrote:
You can commit the patch if any more critical bug reports
for 1.0.3 in this week.Sorry, but I don$B!G(Bt understand what you mean.
Ah… Sorry for my too broken English…
Here is corrected version:
You can commit the patch if anyone doesn’t submit a critical
bug report for 1.0.3 in this week.
But could you split your large patch
to small patches (because I can’t review a large patch…)Well, it$B!G(Bs kind of hard to do so, especially with Subversion.
I could split it across the various sub-projects, I suppose (atk, glib2,
$B!D(B).I$B!G(Bll attach the patch and you can decide if/how I should apply it.
Oh… It’s too large…
Please split it across the sub-projects.
and write user visible changes to NEWS file (because I
don’t want to need many works for collecting changes at the
release time…)?OK, I$B!G(Bll mention the new macros (not yet included in the attached patch).
Thanks!
Please note that there are more of these problems in many of the
libraries. I need to go through all g_new and ALLOC_N calls as well.
OK.
–
kou
2011/9/19 Kouhei S. [email protected]:
Nikolai W. [email protected] wrote:
You can commit the patch if any more critical bug reports
for 1.0.3 in this week.Sorry, but I don’t understand what you mean.
Ah… Sorry for my too broken English…
No problem. Your English is generally very good.
Here is corrected version:
You can commit the patch if anyone doesn’t submit a critical
bug report for 1.0.3 in this week.
So we’re basically at a code freeze now?
Can I thus begin moving the repository to GitHub? That way I can
create a branch there and you can merge it when you see fit.
Oh… It’s too large…
Please split it across the sub-projects.
Will do. I’ll try splitting it into smaller chunks than that, but
I’ll do it against the GitHub repository instead, so I’ll put off
doing this until then.
Sorry for my too broken English.
Your english is good kou!
We understand it 98.5% all the time. And that’s enough. 