On 15.06.2023 18:58:04, Vincent MAILHOL wrote: > > Lastly, I'm not a CAN maintainer. But I think it's usual to separate > > fixes and enhancements into different series, likely the former > > targeting the can tree while the latter targets the can-next tree > > (I could be way off here). > > Hmm... The fact is that only the first two patches are fixes. The > third one is not. The fixes being really minor, there is no urgency. > So I was thinking of having the full series go to the next branch and > as long as there is the Fix: tag, the two first patches will > eventually be picked by the stable team. I thought that this approach > was easier than sending two fixes to the stable branch, wait for these > to propagate to next and then send a second series of a single patch > for next. > > @Marc, let me know what you prefer. I am fine to split if this works > best for you. Also, I will wait for your answer before doing any > resend. > > > If on the other hand, the patches in this series are not bug fixes, > > then it is probably best to drop the 'fixes' language. > > I will keep the Fix tags. Even if minor (probably no visible > repercussions) it still fixes an existing inaccuracy (whether you call > it bug or not is another debate, but I often see typo fixes being > backported, and these are a bit more than a typo fix). I've taken the whole series as is to linux-can-next. Thanks, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung Nürnberg | Phone: +49-5121-206917-129 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
Attachment:
signature.asc
Description: PGP signature
