Re: How to handle NMUs in salsa

[Drew Parsons <dparsons@debian.org>]

On 2024-05-10 23:54, Santiago Vila wrote:
> El 10/5/24 a las 23:33, Drew Parsons escribió:
> > On 2024-05-10 20:30, Santiago Vila wrote:
> > > Hello.
> > >
> > > Need some guidance here: It is ok if I commit to salsa the NMU of
> > > slepc made by Benjamin Drung for the t64 transition?
> > > (The package is already in testing and unstable)
> > >
> > > I ask because I want to report (and maybe fix myself) a makefile bug.
> > >
> > > Also: The question is both about this precise case but also about
> > > any general guideline for that that may exist or should be followed.
> > >
> > > Thanks.
> >
> > No, please do not do that.  The patch is incredibly invasive.
> > I've filed a request to move on with slepc 3.20
>
> Ok, I'm not doing anything, but sorry, I'm a little bit lost here.
>
> Do not do exactly what?
>
> We don't want git history to reflect actual releases?
>
> If yes: Do you mean that NMU release 3.19.2+dfsg1-2.1 will not appear
> in git history at all? (I did not know such thing was 
> allowed/accepted).

Definitely do not want this patch in the code base.  Unless you want to 
revert it immediately after.

> Or maybe do you refer (by "invasive") to the patch required to fix
> the makefile bug which I have not even reported yet? (I believe
> this is less likely what you meant, but I'm not 100% sure).
>
> Could you please clarify?

No no, your makefile bug is something else.  I'm talking about the t64 
patch.

Good to report the problem with makefile so we know what the issue is.

> (btw: Didn't realize there was a 3.20 release in experimental,
> will test it before reporting anything, thanks!)

Great :)  Upstream is reasonably conservative, likely your makefile 
problem will still be there but good to check.

They've already released 3.21 by the way, but I don't plan to package it 
before 3.20 is pushed to unstable.

Drew