On Tue, Jul 26, 2016 at 01:53:11PM -0000, Nish Aravamudan wrote:
> So we do need to clean up this documentation a bit, but I was wondering
> if you think we should just drop this delta? That is, I think the only
> reason to have a Xs-Debian-* field is if we are replacing it (like we do
> with the maintainer). Given the lack of UDD/bzr trees for source
> packages in Ubuntu, I think we don't need to carry the delta.
I'm interested to know what the ubuntu-devel ML thinks of this. I have
no strong opinion either way, but I do think there's value in being
consistent. Consistency would help with onboarding, documentation and
automation with tooling.
> At the same time, is there a tool that updates the VCS informtion like
> `update-maintainer`? Do we want to extend `update-metadata` to do this?
I wonder if we should teach 'update-maintainer' to do whatever
ubuntu-devel ML consensus is that we should do, and possibly rename it
if required.
I believe some (Ubuntu) teams do maintain their delta in VCS, and so do
add the field.
If we are adding our own VCS trees, then I suppose that cannot easily be
automated - but at least the rename of the original VCS could be done by
a tool, and then addition of our own VCS trees could be an actual part
of the delta. Exceptionally, just like update-maintainer, I don't think
there's any need to document such a delta in the changelog. Perhaps our
tooling could learn this somehow.
Hi Nish,
On Tue, Jul 26, 2016 at 01:53:11PM -0000, Nish Aravamudan wrote:
> So we do need to clean up this documentation a bit, but I was wondering
> if you think we should just drop this delta? That is, I think the only
> reason to have a Xs-Debian-* field is if we are replacing it (like we do
> with the maintainer). Given the lack of UDD/bzr trees for source
> packages in Ubuntu, I think we don't need to carry the delta.
I'm interested to know what the ubuntu-devel ML thinks of this. I have
no strong opinion either way, but I do think there's value in being
consistent. Consistency would help with onboarding, documentation and
automation with tooling.
> At the same time, is there a tool that updates the VCS informtion like maintainer` ? Do we want to extend `update-metadata` to do this?
> `update-
I wonder if we should teach 'update-maintainer' to do whatever
ubuntu-devel ML consensus is that we should do, and possibly rename it
if required.
I believe some (Ubuntu) teams do maintain their delta in VCS, and so do
add the field.
If we are adding our own VCS trees, then I suppose that cannot easily be
automated - but at least the rename of the original VCS could be done by
a tool, and then addition of our own VCS trees could be an actual part
of the delta. Exceptionally, just like update-maintainer, I don't think
there's any need to document such a delta in the changelog. Perhaps our
tooling could learn this somehow.