Bug#720507: .dsc field for dgit [and 1 more messages]
Charles Plessy writes ("Re: Bug#720507: .dsc field for dgit"):
> thank you for your patch and for your work on dgit. In light of the
> discussion about how our infrastructure handles this field, I would
> like to wait for further testing and adoption before adding it to
> the Policy. Please do not hesitate to ping us when you think it is
I'd like to get the field name finalised soon, and also to add the
policy requirement. Joey explains it well.
> About the name, what does "Master" mean ? Isn't that misleading if the
> referenced commit is not on the master branch ?
Perhaps it is.
I'm certainly not wedded to the name. "Dgit-Commit" would be an
obvious one but in the future I expect it to contain more than one
commit hash and perhaps other information. Is just "Dgit" too
> Lastly, in case of the dgit repositories would move from the Alioth project
> 'dgit-repos' to somewhere else, could you propose a wording that is more
> generic, and that is more explicit on what a 'dgit-repos' is ?
"dgit-repos" is precisely the name for the canonical location in which
these commits can be found.
> PS: off-topic question: do you have comments to make about the documentation
> of Dpkg's triggers to the Policy ?
I'm afraid I haven't had a chance to review that. Is it any different
in semantics to the original triggers text file document ?
Joey Hess writes ("Re: Bug#720507: .dsc field for dgit"):
> AIUI this is because packages move between suites in the archive without
> that move necessarily being immediately reflected in a git repository.
> Also because dgit doesn't need that invariant to work properly.
> It may be too early to put a MUST in policy that would be
> broken if dgit.debian.net went away tomorrow.
I think that the right approach to that would be to remove the item
from policy again, or to regard it as a bug in dgit.debian.net.
> But I think what Ian is trying to do here is avoid the archive and
> dgit.debian.net becoming inconsistent due to a botched upload, as
> long as dgit.debian.net continues to exist and continues to contain
> a repository for a given package. It's reasonable to consider such
> an inconsistency a bug in the package, unless it somehow turns out
> to be a bug in dgit.debian.net.
Yes. I would go further: even if the repo doesn't exist for that
specific package, it is a problem.
I think the right way is my wording. If it turns out that
dgit.debian.net breaks then that's a bug in dgit.debian.net. If the
package has a broken state then it should be rectified somehow.
dgit.debian.net is only going to go away entirely if we consider the
whole thing a failed experiment (and perhaps not even then).