Re: yasnippet commits review

[Aymeric Agon-Rambosson <aymeric.agon@yandex.com>]

Hi Nicholas,

Le dimanche 29 janvier 2023 à 13:51, Nicholas D Steeves 
<sten@debian.org> a écrit :

> I agree, the wiki is a good place to centralise information. 
> Linking to
> that article can then be used to avoid needing to reexplaining 
> things;
> it also prevents gating when you link to it from package that 
> needs a
> workaround--this is especially important for a package that 
> needs
> an active human maintainer!
>
> Another possibility might be to eventually provide additional
> documentation in dh-elpa.

Feel free to use any part of my previous mails verbatim if you 
edit the wiki (I don't have write access). If you want me to 
review it first, just tell me.

> Thanks!  That will fulfil #1 of the above.

This is done.

> The "not with a patch" alternative is valid but I worry it may 
> be
> insufficient, so I would need to see what you're proposing...and 
> we're
> short on time...for the record, here's my criteria:
>
>   1. Don't make Debian-specific fixes (make them upstream, and 
>   make the
>   same changes in the Debian package), except for 
>   Debian-specific issues
>   2. Provide the URL where fix was forwarded
>   3. It's better if no further action needs to be taken when 
>   rebasing
>   the Debian package on a future (fixed) upstream version
>   4. Optionally provide a link to upstream bug (in this case, it 
>   sounds
>   like that would be an Emacs bug).  In the absence of this, it 
>   would be
>   nice to see it as a TODO item, because we're supposed to be 
>   helping
>   upstream work towards a more robust future.
>   5. Don't normalise the bug or take on technical debt--I feel 
>   like
>   a simple use of d/elpa-test would probably do this, because 
>   this file
>   is usually used for permanent Debian-specific CI integration 
>   type
>   problems...also, if it's truly an Emacs then I think that 
>   dh-elpa
>   is the place to implement the workaround.

Fair enough, I went with the patch.

> > > Go ahead and finalise the changelog
> > > with a commit message that mentions the version
> > > (0.14.0+git20200603.5cbdbf0d-2) as well as the 
> > > distribution/suite
> > > (unstable)--in other words, it's just about ready to sponsor.

Done, the package should be ready to upload.

Best,

Aymeric