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

Reply via email to