Re: [g-a-devel] Could we release new Accerciser version ?

[apinheiro <apinheiro igalia com>]

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]apinheiro 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 <mrobinson 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