On Wed, 2015-05-27 at 11:41 +0200, IOhannes m zmölnig (Debian/GNU) wrote: > but then you started to fill up debian/changelog again :-( > > here's some guidelines about debian/changelog: > - debian/changelog is mainly for users to read what happens between > debian packages. it is not to document each and every step you did for > doing the packaging. esp. when it comes to initial packaging, there is > little point in documenting e.g. that you added a debian/ directory. > - the git history is for tracking any changes needed to get the > packaging done. personally i think that one should apply the same > atomic commit principle as in any other software development. simply > put: more commits is better. (no matter how banal they are).
Hi, I think the same way basically. In my case, as a user of a package, I'd like to see at which point what patches were added/changed/removed to see how the package differs from upstream behaviour, that's why I added that line in changelog. I trimmed the changelog, but left the line about the patch. I hope you are ok with that. > - always keep in mind that the two are separate. they have different > visibility by intention: people that *install* the package, check > debian/changelog; people that *maintain* the package, check `git log` > > now there is this handy tool "gbp dch" that will create a > debian/changelog from the git history. > it's cool, as more often than not the git history and the > debian/changelog match closely. I already used it for other packages. However, it can't create the initial changelog as it seems, so I used dch for now. > keeping the full history in git (rather than squashing commits into a > single one), is important for review. > > when i review your package, i'm not very intersted in reviewing the > same stuff over and over. > as soon as you temper with history (and squashing commits is just > that), you create additional work for me, as now i cannot do an > incremental review based on my last one, but instead you force me to > start from scratch :-( Sorry for that. Usually I never rebase published branches. > finally: don't set the release-target in debian/changelog to anything > but UNRELEASED until the package is to be uploaded. > the exact point when the package is ready is currently to be > determined by your sponsors rather than yourself, so just leave it at > UNRELEASED. OK, I'll do that in future versions and changed that in the git repository. > hmm, i don't fully understand this. > the name ptp4l.conf was important as long as that file lived in /etc > (/etc/default.conf is a tad generic). > but now that you have a separate directory, i don't see any reason to > not keep the original name: /etc/linuxptp/default.cfg is an easy to > understand and remember name, and does not require any special dh-exec > hacks at all. (less cruft, less dependencies,...) IMHO /etc/linuxptp/default.cfg could be mistaken as a set of defaults for all binaries in the package. However, it belongs to ptp4l, therefore I named it ptp4l.conf. The same goes for timemaster, which uses timemaster.conf. According to the git log, the file name in the upstream archive goes back to a date when there was only the ptp4l binary. All other binaries were added after this. How will maintainership within the debian-multimedia team work? Where will the git repository be hosted? I already have a guest account for collab-maint on git.debian.org. I hope you are ok withe the current state of the package. Regards, Tino _______________________________________________ pkg-multimedia-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
