Tooling (or process) doesn't handle VCS- fields

Hey Robie,

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.

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?

-Nish

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

On Tue, Jul 26, 2016 at 4:29 PM, Robie Basak <email address hidden> wrote:
> 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
>> `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.

Makes total sense to me. I will work on writing something up this week.

I will say the reason this is even a thing we noticed is that we can't
simply drop the changes (or have the be combined with a
'update-metadata' commit) in our process during the rebase, as there
isn't a tool that can 'replay' them like `update-maintainer` does.

Also see bug 1707327