Seeking for sponsorship for linuxptp (PTP/IEEE1588 implementation)

[Tino Mettler]

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