Seeking for sponsorship for linuxptp (PTP/IEEE1588 implementation)

IOhannes m zmölnig (Debian/GNU) umlaeute at debian.org
Wed May 27 09:41:31 UTC 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2015-05-27 09:49, Tino Mettler wrote:
> I prepared a new repository.

cool.

>> - as this package has never been in debian before, you can trim
>> the debian/changelog to a bare minimum (that is: a single section
>> for "1.5-1" [sic!])
> 
> Done.


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).

- - 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.
but again, the two are not the same.
which means that you should *always* check debian/changelog after
re-generating it via `gbp dch`, and amend it for a proper changelog.

e.g. if you try to fix a specific problem it might well take a few
iterations (e.g. first using a plain debian/install; not being happy
that it gives you an /etc/linuxptp/foo.cfg when you really want
/etc/linuxptp/bar.cfg; so you then switch to dh-exec,...)
there is nothing wrong with that.
keeping that history around is actually good, as it documents your
decisions and allows us to learn from it).
but it's not very interesting in debian/changelog. so after running
`gbp dch` you should edit the changelog file to merge all those atomic
commits into a single entry (probably using sub-entries if applicable).


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 :-(

so please: commit commit commit.

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.

>> it also might make a bit more sense to use "eth1" in the example
>> (as the example you give does changes the behaviour to the
>> original one :-))
> 
> The idea of the example was to put in the default values so the
> user can change them to the desired values.

makes sense.

> 
>> - configuration files: any reasons you don't put all
>> configuration files into /etc/ptp4l/ ? this might allow you to
>> replace the override_dh_auto_install cruft by a simple
>> debian/install file (but this might rename the /etc/ptp4l.conf
>> to /etc/ptp4l/default.conf)
> 
> Now all configuration files are installed in /etc/linuxptp/. The
> name of ptp4l.conf is kept by using dh-exec in debian/install.
> 

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,...)

fgmasdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVZZFLAAoJELZQGcR/ejb4OtwP/3ABSM4gF9/vDbHSOobU0DhY
4IVzMp9ZMPqxTy1J5YOpJWsoQZ12zG46wMj/w+RqH5i9T0dQIPDl8EIO+sXVHs/3
eFRV4lOjTKVSU5LAd5Z/SEvzKTXtPUtANrE3yr3hgTKsoXKh4yYzV9/0sD6kwFCC
NzRd4hbm8V+cN+u4kuC5SjqbPrKtqiacOZeR1Ij3iTFFzJ+yi//Y0BYyBVEZ1DxA
IR3FKy0xuoe1SuprBmfFAv3Kcn4hA1UDX+fzs4H3GvaYCx527NbYb+N9hK4LZDaL
4JJAbdH/lQB/rE6NeAbSljXVRxU8TUkI2txppPao015PigkjWZmk0FgAtEdRSAnr
VVxgz2tGU2bx9hRr+bCddYr7rJODzZebB32hC/h8uoOx6mt/tFi0eQcZ14yCPSiY
arAPGebkEyp0tvO98n8GljQeZ0j8cudBJcbiOhMJs9+0fi6ME1ahA0ZE/k95VIGb
DEmaReXX+D+g32hEgbRf1oMz9j7Ctki52fBhYfSbwSAxQcVQLqKqSomMBsolAE6e
30URpZgeYuel5gcpBIwpy14MfAqZTiX357mBXcgluhjUJyoXHr71riYv2wi3DSzm
HKTNe8gJunvYi8aP9rYJfRx4/P65gXmnyaNAkEwaxSJjuGZeWvAx4Kl8xira8y6V
XoRnEJHXcdYnsDy43mkJ
=37uS
-----END PGP SIGNATURE-----



More information about the pkg-multimedia-maintainers mailing list