Hi, On 2012-06-29 14:24, david.sephi...@gmail.com wrote: > > Good. Another point which I now noticed is that you want to lowercase > > the short description: s/Picks out/picks out/. So, please fix that, add > > Vcs-* headers, fix changelog corrections above and I'll upload the > > package. > > OK, thanks for point out the typos :) > > driftnet/0.1.6+cvs20040426-2 uploaded, you can find it at: > http://mentors.debian.net/debian/pool/main/d/driftnet/driftnet_0.1.6+cvs20040426-2.dsc
First, under 'bumping revision' I meant leaving previous -1 changelog entry intact (except of grammatic fixes), and starting new -2 entry, with mentioning latest changes you did (Vcs-* and lowercasing short description). Think of it as you'd prepare a new version for official Debian archive. My view is 'don't ever rewrite the history, except of fixing non-normative things like indentation or typos or grammar fixes'. Note, again, above are my preferences, other people may prefer other schemes. Secondly, Vcs-* should point to your packaging (Git, as I understood) repository, not upstream. Or is your packaging repository not public? Then don't add any Vcs-* fields for now. Since you uploaded -2 already, I now want -3. Leave your original -1 changes (only apply grammar fixes to them) under "-1", make new "-3" changelog entry, and document all your changes which you made after my review in it (probably it'd nice to mention that you applied some fixes to the previous changelog entry). > Because the next mayor change I will implement is to add ipv6 support > (currently I have patch for it but Im still testing and working on it) and I > dont want to piss off the Chris work, Im thinking about to rename the fork > 'drfitnet6'. > > About that I have a pair of questions: > > - Can i maintain the current version numbering of the original > driftnet > package and start working in the fork from it ? This is not for Debian or me to decide, but I personally think you can use whatever version scheme you want. > - Can debian provide with git repositories in that I can host the > package > and the upstream code ? Since upcoming upstream code is not specific to Debian, I'd maintain it at some neutral shared service, such as Github or Bitbucket. As for Debian packaging, you can use Alioth [1], or alternatively just keep it at the same service where upstream code will be located. [1] http://alioth.debian.org/ -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
