On 19.03.19 16:20, Łukasz Zemczak wrote:
> Looking at this with my SRU hat on, I'd prefer if we could avoid
> backporting a completely new upstream version to bionic especially if
> there is a soname bump involved. It's not impossible of course, we do
> that for certain projects when there's need for it, but I'd suppose we
> would require a 'hard' rationale for that. Not sure if we have a strong
> one like that here.
>
> Security team - what changes/bugfixes do you think would be needed
> before the package is good for main in those stable series? Such
> information would also be very useful for us in the SRU team to assess
> the situation. We could then decide if the gvfs nfs support feature is a
> no-go, the libnfs security-bugfix changes need to be cherry-picked or
> maybe the rationale for 3.0.0 should be revisit.
the MIR team asked for the new upstream for promotion. Now promoting the old
version for older releases wouldn't be much appreciated.
On 19.03.19 16:20, Łukasz Zemczak wrote:
> Looking at this with my SRU hat on, I'd prefer if we could avoid
> backporting a completely new upstream version to bionic especially if
> there is a soname bump involved. It's not impossible of course, we do
> that for certain projects when there's need for it, but I'd suppose we
> would require a 'hard' rationale for that. Not sure if we have a strong
> one like that here.
>
> Security team - what changes/bugfixes do you think would be needed
> before the package is good for main in those stable series? Such
> information would also be very useful for us in the SRU team to assess
> the situation. We could then decide if the gvfs nfs support feature is a
> no-go, the libnfs security-bugfix changes need to be cherry-picked or
> maybe the rationale for 3.0.0 should be revisit.
the MIR team asked for the new upstream for promotion. Now promoting the old
version for older releases wouldn't be much appreciated.