[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


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


Reply to: