On 22/3/19 19:40, Samuel Thibault wrote:
Samuel Thibault, le ven. 22 mars 2019 14:21:43 +0100, a ecrit:
Javier Hernandez via gnome-accessibility-list, le mer. 20 mars 2019 11:56:36
+0100, a ecrit:
There is the Maintainers Corner [1], where you can find all the information you
need to know in order to maintain a module.
Thanks! I won't have time do spend on it in the coming days, but I can
have a look a bit later.
jhbuild setup went smoothlier than I expected, so I'm ready to make a
release.
On Wed, Mar 20, 2019 at 11:28 AM apinheiro <[2]apinhe...@igalia.com> wrote:
(I could check that the current git master does work fine here)
First: take into account that I'm not sure if at this point you can add
more functionality to a 3.31.X/3.32.X Accerciser release, due the
freezes.
Sure. But what was already in 3.31.4 is fine for 3.32, right?
The only notable commit I can see since then is "Stop using intltool",
which is a build fix, not source code change, so it should be fine.
Actually, AIUI, the freeze is only for uncommitted code, so what is
already in master can be just uploaded?
No, the freezes are about changes on releases. Changes can be still
committed to master, but the freezes are about what you include on
following releases. In some cases, you see comments like "please push on
master after freezes" just because it makes it easier to make the
releases, as you don't need to filter those commits, not because the
freezes stops you to push on master.
Let's use a recent example on ATK. On February 19 I made release
2.31.92. After that, I reviewed atk!14("Fix failure value for
atk_text_get_caret_offset"), and I asked Martin to push the change on
master. So the following commit is on master now (so committed):
"commit 951b1e9b9fd47e3b36c0bd43f0d7782e9dc0eb1a
Author: Martin Robinson <mrobin...@igalia.com>
Date: Fri Feb 22 09:21:46 2019 +0100
Fix failure value for atk_text_get_caret_offset
atk_text_get_caret_offset should return -1 if the caret is not located
within the element or for other failures. This will allow clients to
distinguish between a failure and when the caret is at offset 0."
Although small, that change is technically an API change. So it was
affected by the freezes. Next release I have in mind was 2.32, but I
should not include it without release team approval. I created a thread
on release-team ml to discuss it [1], and we finally agreed to not
include this commit, because although some applications were already
using the correct value, others where using the old (incorrect) value
(like gtk).
So, when I rolled ATK 2.32 I didn't include that commit, even if it was
already committed on master. If you are interested, what I did was
create in advance the gnome-3-32 branch (the one I would use to maintain
the atk 2.32.X, just in case I backport a change to atk stable),
without that commit. You can see that branch as reference here :
https://gitlab.gnome.org/GNOME/atk/commits/gnome-3-32
BR
[1] https://mail.gnome.org/archives/release-team/2019-March/msg00054.html
Samuel
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list