Tails

#1 Updated by segfault 2018-08-05 19:00:36

Matthias Clasen told me today on IRC that

• GTK+ 3.24 will be released with GNOME 3.30
• They don’t have any hard freezes, but try to follow the GNOME cycle to some degree
• He is sorry he didn’t follow up on our merge requests more actively, and that he will be unavailable the next 10 days, so now Emmanuele Bassi will take over the reviews.

#2 Updated by segfault 2018-08-05 19:01:56

Also, at least https://gitlab.gnome.org/GNOME/gtk/merge_requests/200 will definitely not make it into GTK 3.24, because it is now clear that it requires a further patch to GVfs, which won’t be part of GNOME 3.30.

#3 Updated by intrigeri 2018-08-07 09:56:08

Thanks for the updates. So it seems that we need to slightly redefine our criteria for completion of this project. Please propose something and then let’s discuss it :)

#8 Updated by intrigeri 2018-09-04 11:28:08

Oh, and sorry: I should definitely have raised this topic at the last VeraCrypt team meeting!

#9 Updated by segfault 2018-09-04 20:09:29

intrigeri wrote:
> Hold on: as much as I would love to be able to call this done, the fact that GTK+ 3.24 was released already without all our patches does not solve the problems at hand, it rather makes them harder.

Of course, but I thought it would make it obsolete to “organize our work wrt. GTK+ 3.24.x release schedule”.

> Perhaps you’ve missed Feature #15761#note-3, which would explain why you’ve closed this ticket.

I misunderstood what you wanted me to do on this ticket.

> To clarify what we’re talking about, I had a quick look and I’ve found these remaining MRs:
>
> * https://gitlab.gnome.org/GNOME/gtk/merge_requests/244
> * https://gitlab.gnome.org/GNOME/gtk/merge_requests/262
> * https://gitlab.gnome.org/GNOME/gtk/merge_requests/289 → what’s the corresponding current GTK+ 3.x MR by the way?

There is none, because there is no 3.X branch I could base it on and AFAIK it is not planned that there will any more GTK+ 3.X releases.

> * https://gitlab.gnome.org/GNOME/gtk/merge_requests/220 → what’s the corresponding current GTK+ 3.x MR by the way?

I closed this one because it was superseded by 289.

> I don’t want to be a PITA so I’ll spell out myself the cases I can think of:
>
> * Our work is merged into GNOME 3.30.x maintenance releases (gvfs, GTK+) by the end of October and then we can stick to the initial success criteria and likely we can get this into Buster so no need to maintain patched packages for 2 more years. Is there any chance this happens? I suspect this would conflict too much with their stable branches policy but I don’t know how they do things at GNOME usually. I think this requires communication with the relevant upstream maintainers.

I didn’t know that would be an option, because I didn’t know that GNOME has maintenance releases which could allow new features. But I don’t think this will work, Ondrej Holy knows that we want our merge requests to go into GNOME 3.30, and he wrote on the GVfs merge request that it will probably have to go in 3.32: https://gitlab.gnome.org/GNOME/gvfs/merge_requests/7#note_295649

> * Our work is merged into the upstream gtk-3-24 branch by the end of October but does not make it into Buster. Then we can stick to the initial success criteria but we have to maintain patched packages for 2 more years, so be it. Seems realistic?

Yes, seems realistic to me.

> * Our work is not merged upstream by the end of October. That’s the worst case scenario. Then well, we’ll explain the sponsor that we have submitted the work upstream N months in advance but they’re lagging behind. But in this case, please make sure you ping upstream regularly somehow, to make our case stronger… and increase the chances that the 2nd option above succeeds.

I just pinged them on all three remaining tickets. And good news: the CI now passes on the GTK+ tickets, so I’m confident we can get those merged - or at least get some comments on the code - soonish.

> Here again, we have to maintain patched packages for 2 more years, so be it.
> * Any other possibility?

I don’t see any other possibility.

> I’d like us to know soon what’s feasible and then prioritize resources accordingly.

This I don’t really get. And I think it is also why I didn’t get what you wanted from me with this ticket. What is there to prioritize? We know that we have to get our stuff upstreamed ASAP, else it will be more maintenance overhead for us. That’s what we’re telling upstream since months.

#10 Updated by intrigeri 2018-09-05 15:43:06

hey!

segfault wrote:
> intrigeri wrote:
>> Perhaps you’ve missed Feature #15761#note-3, which would explain why you’ve closed this ticket.

> I misunderstood what you wanted me to do on this ticket.

OK. I hereby claim my share of responsibility for this.

>> * https://gitlab.gnome.org/GNOME/gtk/merge_requests/289 → what’s the corresponding current GTK+ 3.x MR by the way?

> There is none, because there is no 3.X branch I could base it on and AFAIK it is not planned that there will any more GTK+ 3.X releases.

I understand there won’t be a GTK+ 3.26. Sorry I was unclear, I meant GTK+ 3.24.x rather than GTK+ 3.x :)
To me it looks like there will be further 3.24.x releases:

• The gtk-3-24 branch already has commits on top of the 3.24.0 tag.
• There are plenty of MRs labeled GTK3

And it seems you agree because below you wrote that “merged into the upstream gtk-3-24 branch by the end of October” is realistic.

Now, whether our remaining stuff qualifies or not, is another matter (that’s discussed below).

>> * Our work is merged into GNOME 3.30.x maintenance releases (gvfs, GTK+) by the end of October and then we can stick to the initial success criteria and likely we can get this into Buster so no need to maintain patched packages for 2 more years. Is there any chance this happens? I suspect this would conflict too much with their stable branches policy but I don’t know how they do things at GNOME usually. I think this requires communication with the relevant upstream maintainers.

> I didn’t know that would be an option, because I didn’t know that GNOME has maintenance releases which could allow new features.

Right, that’s not allowed (at least in theory) but FWIW I’ve seen GNOME use a rather relaxed definition of “bugfix” in their point releases ;) I suspect some of your MRs might qualify but perhaps it’s not worth the effort (there’s a fine line between bullying/annoying maintainers and finding out where the line is exactly).

> But I don’t think this will work, Ondrej Holy knows that we want our merge requests to go into GNOME 3.30, and he wrote on the GVfs merge request that it will probably have to go in 3.32: https://gitlab.gnome.org/GNOME/gvfs/merge_requests/7#note_295649

OK, thanks! So at least https://gitlab.gnome.org/GNOME/gtk/merge_requests/289 is out because it depends on gvfs!7.

>> * Our work is merged into the upstream gtk-3-24 branch by the end of October but does not make it into Buster. Then we can stick to the initial success criteria but we have to maintain patched packages for 2 more years, so be it. Seems realistic?

> Yes, seems realistic to me.

Great, let’s do that then, assuming you took into account the “into the upstream gtk-3-24 branch” part, and then we do need a GTK+3 version of https://gitlab.gnome.org/GNOME/gtk/merge_requests/289. But I’m confused: I doubt 3.24.1 will have stuff that depends on a gvfs that won’t make it into GNOME 3.30.1. Or will it?

> I just pinged them on all three remaining tickets. And good news: the CI now passes on the GTK+ tickets, so I’m confident we can get those merged - or at least get some comments on the code - soonish.

Excellent! Now, sorry if I’m still a GitLab newbie: I see no such ping on https://gitlab.gnome.org/GNOME/gtk/merge_requests/244 nor https://gitlab.gnome.org/GNOME/gtk/merge_requests/262.

>> I’d like us to know soon what’s feasible and then prioritize resources accordingly.

> This I don’t really get. And I think it is also why I didn’t get what you wanted from me with this ticket. What is there to prioritize? We know that we have to get our stuff upstreamed ASAP, else it will be more maintenance overhead for us. That’s what we’re telling upstream since months.

Sure! Here’s some background behind this sentence of mine:

• There are other remaining tasks (apart of upstreaming) e.g. Feature #15524 and IIRC you were trying to fix a patch you had to revert; I would like to prioritize them vs. the upstreaming work.
• If pushing a bit harder to get stuff upstreamed in due time will save us lots of our time later, that might be doable: we have other resources than your own time :)
• Depending on whether pushing a bit harder to get stuff upstreamed will buy us anything or not, we can adjust the pinging frequency and where you focus your Tails work: you have other things on your plate than VeraCrypt :)

Granted, all this might not make a big difference and is not worth spending too much time on. Let’s not over-engineer it. So basically, tl;dr: are we aiming for GTK+ 3.24.x or not?

#11 Updated by segfault 2018-09-07 22:37:28

intrigeri wrote:
> >> * https://gitlab.gnome.org/GNOME/gtk/merge_requests/289 → what’s the corresponding current GTK+ 3.x MR by the way?
>
> > There is none, because there is no 3.X branch I could base it on and AFAIK it is not planned that there will any more GTK+ 3.X releases.
>
> I understand there won’t be a GTK+ 3.26. Sorry I was unclear, I meant GTK+ 3.24.x rather than GTK+ 3.x :)
> To me it looks like there will be further 3.24.x releases:
>
> * The gtk-3-24 branch already has commits on top of the 3.24.0 tag.
> * There are plenty of MRs labeled GTK3

I see.

> And it seems you agree because below you wrote that “merged into the upstream gtk-3-24 branch by the end of October” is realistic.

Actually, I overlooked the gtk-3-24 part, see my reply below.

> >> * Our work is merged into GNOME 3.30.x maintenance releases (gvfs, GTK+) by the end of October and then we can stick to the initial success criteria and likely we can get this into Buster so no need to maintain patched packages for 2 more years. Is there any chance this happens? I suspect this would conflict too much with their stable branches policy but I don’t know how they do things at GNOME usually. I think this requires communication with the relevant upstream maintainers.
>
> > I didn’t know that would be an option, because I didn’t know that GNOME has maintenance releases which could allow new features.
>
> Right, that’s not allowed (at least in theory) but FWIW I’ve seen GNOME use a rather relaxed definition of “bugfix” in their point releases ;) I suspect some of your MRs might qualify but perhaps it’s not worth the effort (there’s a fine line between bullying/annoying maintainers and finding out where the line is exactly).

OK.

> > But I don’t think this will work, Ondrej Holy knows that we want our merge requests to go into GNOME 3.30, and he wrote on the GVfs merge request that it will probably have to go in 3.32: https://gitlab.gnome.org/GNOME/gvfs/merge_requests/7#note_295649
>
> OK, thanks! So at least https://gitlab.gnome.org/GNOME/gtk/merge_requests/289 is out because it depends on gvfs!7.

Right.

> >> * Our work is merged into the upstream gtk-3-24 branch by the end of October but does not make it into Buster. Then we can stick to the initial success criteria but we have to maintain patched packages for 2 more years, so be it. Seems realistic?
>
> > Yes, seems realistic to me.
>
> Great, let’s do that then, assuming you took into account the “into the upstream gtk-3-24 branch” part, and then we do need a GTK+3 version of https://gitlab.gnome.org/GNOME/gtk/merge_requests/289. But I’m confused: I doubt 3.24.1 will have stuff that depends on a gvfs that won’t make it into GNOME 3.30.1. Or will it?

I overlooked the gtk-3-24 part and thought we were talking about upstreaming to GTK+ in general. And I think the result would be the same: “Then we can stick to the initial success criteria but we have to maintain patched packages for 2 more years, so be it.” Why is it important that we get it into GTK+3?

> > I just pinged them on all three remaining tickets. And good news: the CI now passes on the GTK+ tickets, so I’m confident we can get those merged - or at least get some comments on the code - soonish.
>
> Excellent! Now, sorry if I’m still a GitLab newbie: I see no such ping on https://gitlab.gnome.org/GNOME/gtk/merge_requests/244 nor https://gitlab.gnome.org/GNOME/gtk/merge_requests/262.

I didn’t ping on those before, because I thought that those couldn’t be merged anymore. I now asked about the CI failure on gtk!262. The reply will also be relevant for gtk!244, but this one won’t be of any use without the gnome-shell patch anyway.

> >> I’d like us to know soon what’s feasible and then prioritize resources accordingly.
>
> > This I don’t really get. And I think it is also why I didn’t get what you wanted from me with this ticket. What is there to prioritize? We know that we have to get our stuff upstreamed ASAP, else it will be more maintenance overhead for us. That’s what we’re telling upstream since months.
>
> Sure! Here’s some background behind this sentence of mine:
>
> * There are other remaining tasks (apart of upstreaming) e.g. Feature #15524 and IIRC you were trying to fix a patch you had to revert; I would like to prioritize them vs. the upstreaming work.
> * If pushing a bit harder to get stuff upstreamed in due time will save us lots of our time later, that might be doable: we have other resources than your own time :)
> * Depending on whether pushing a bit harder to get stuff upstreamed will buy us anything or not, we can adjust the pinging frequency and where you focus your Tails work: you have other things on your plate than VeraCrypt :)

OK, thanks for explaining.

> Granted, all this might not make a big difference and is not worth spending too much time on. Let’s not over-engineer it. So basically, tl;dr: are we aiming for GTK+ 3.24.x or not?

It’s clear that we will have to maintain GTK (because of gtk!289), GVfs (because of gvfs!7), and GNOME Shell (because of gnome-shell!126) anyway. So I don’t think it would save us much time to get the other patches into GTK+ 3.24.x. It would of course be nice to have them in Buster, because then a lot more users will benefit from them earlier. But I don’t think we should put too much effort in it.

#12 Updated by intrigeri 2018-09-10 12:09:04

hi!

segfault wrote:

> intrigeri wrote:
>> >> * Our work is merged into the upstream gtk-3-24 branch by the end of October but does not make it into Buster. Then we can stick to the initial success criteria but we have to maintain patched packages for 2 more years, so be it. Seems realistic?
>>
>> > Yes, seems realistic to me.
>>
>> Great, let’s do that then, assuming you took into account the “into the upstream gtk-3-24 branch” part, and then we do need a GTK+3 version of https://gitlab.gnome.org/GNOME/gtk/merge_requests/289. But I’m confused: I doubt 3.24.1 will have stuff that depends on a gvfs that won’t make it into GNOME 3.30.1. Or will it?

> I overlooked the gtk-3-24 part and thought we were talking about upstreaming to GTK+ in general. And I think the result would be the same: “Then we can stick to the initial success criteria but we have to maintain patched packages for 2 more years, so be it.” Why is it important that we get it into GTK+3?

It is important because the initial goal was to add “VeraCrypt support in GNOME”. Until GNOME uses GTK+4, the fact this code is merged into GTK+4 does not give any immediate benefit to GNOME users, does it?

>> Excellent! Now, sorry if I’m still a GitLab newbie: I see no such ping on https://gitlab.gnome.org/GNOME/gtk/merge_requests/244 nor https://gitlab.gnome.org/GNOME/gtk/merge_requests/262.

> I didn’t ping on those before, because I thought that those couldn’t be merged anymore. I know asked about the CI failure on gtk!262. The reply will also be relevant for gtk!244, […]

Great!

>> Granted, all this might not make a big difference and is not worth spending too much time on. Let’s not over-engineer it. So basically, tl;dr: are we aiming for GTK+ 3.24.x or not?

> It’s clear that we will have to maintain GTK (because of gtk!289), GVfs (because of gvfs!7), and GNOME Shell (because of gnome-shell!126) anyway. So I don’t think it would save us much time to get the other patches into GTK+ 3.24.x. It would of course be nice to have them in Buster, because then a lot more users will benefit from them earlier. But I don’t think we should put too much effort in it.

I see. Indeed, it’s a matter of Tails-specific priorities and resource allocation vs. having GNOME users outside of Tails benefit from our work. I’m fine with your conclusion!