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
> time.
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
short ?
> 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.
Precisely.
> 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).
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
