Web lists-archives.com

Re: Bug#515856: Debian Policy released

On Thu, Apr 12, 2018 at 09:39:39AM -0700, Russ Allbery wrote:
> > After the removal I will surely stick to my personal policy but for an
> > explanation who to implement it in a somehow standardized way I need do
> > add extra information now.
> You would already have to add some extra information since the Policy text
> was ambiguous.

I agree that this needs fixing.

> Different people interpreted it differently; for instance,
> whether it downloaded the *current* orig.tar.gz file or the one for the
> next upstream release.

This was in fact open for interpretation.

> > As I said before I'm fine with the removal from debian/rules but we
> > should somehow settle with some default recommendation that avoids that
> > every developer invents its own way to obtain the upstream source (if
> > uscan does not work and I'm talking only about this case).
> I don't think agree that this is something Debian *needs*, and I
> personally don't really agree with your sponsorship rule and wouldn't
> apply that rule myself.  (You're of course free to apply any restrictions
> you want to what packages you're willing to sponsor.)  I can see how it's
> very *useful* to automate a common operation like updating to a new
> version of upstream, but I wouldn't make it a requirement, and I also
> don't think this fairly unusual edge case requires standardization.

I do not subscribe the edge case argument.  In the dir where I have
nearly all Git repositories of Debian Med team I have

$ find . -name debian -type d | grep -v \.git | wc -l
$ find . -name get-orig-source -type f | wc -l

I have not checked every single of these and with my recent knowledge
about obtaining the source from Git repositories via uscan some of these
might be droped.  But its roughly 10 percent of the packages (not only
released packages but also not yet finished preparations admittedly and
may be the percentage of get-orig-source scripts is higher there).
> That said, I think guidance for good practices for edge cases is always
> useful if someone wants to write it up, and the Developer's Reference
> seems like a good place to accumulate such things.

I'm not really happy with the "downgrade from policy to Developer's
Reference".  I would have loved if some more precise wording would
have been found for policy but as long as we can settle with some
clarified wording that's OK for me.

Kind regards