> Von: Gianfranco Costamagna [mailto:locutusofborg@debian.org] > [Snip] >> Ah, I see. I assumed that the patch editor would cut the lower part in same >> fashion as git/svn would do. Fixed. > > nack > . > logdata-anomaly-miner (0.0.2-1) unstable; urgency=low > . > * Initial inclusion of logdata-anomaly-miner to Debian > (Closes: #813096) > Author: Roman Fiedler <roman.fiedler@ait.ac.at> > Bug-Debian: https://bugs.debian.org/813096 > > this seems useless ^^^ > you need to close a specific bug, not the itp one > (or just delete the lines if there isn't a debian bug corresponding > to the patch) Understood for the ITP-case. (I assumed "dpkg-source --commit" would have added those lines for a reason, so I kept them). As there is no specific bug to close, I removed all the lines mentioned above EXCEPT the "Author" one, as this should be mandated by "dep3", if understood correctly. What would be the correct way of handling for non-ITP bugs? Should they be only mentioned in the changelog, the patches or both? Some example what I could think about: "Backport of some-logic-flaw from upstream". Does Debian system also use the bug reference entries from patches to auto-close bugs? I assumed, that only changelog-bug references would do that? > [Snip] > I guess we are mostly ok! Seems so. As the upstream native package would also greatly benefit from these changes, I will backport most of the stuff done here for the next version, then we could drop most or perhaps even all of the patches. Would it make sense to keep the sponsor-workflow also for those uploads (pro: learn from sponsor, con: consumes sponsor's time) or becoming a maintainer (pro: shorter upload workflow, con: no second opinion on own work)? Thanks for your patience!
Attachment:
smime.p7s
Description: S/MIME cryptographic signature