t; check the package tracking system for transition warnings to avoid
> making uploads that disrupt ongoing transitions."
Regards,
Bart Martens
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131208060640.ga1...@master.debian.org
license questions applies.
Regards,
Bart Martens
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130630050659.ga3...@master.debian.org
d via Debian.
> (**): Essentially, the exception allows copying of certain trivial parts
> under
> *any* licence terms. Usage in the package in question clearly exceeds what
> is
> covered by the exception.
Exceeds ? Sounds like a problem, but maybe I'm misunderstanding this.
in my opinion, perfectly reasonable to not remove this
click-through disclaimer. I'm not saying that Debian should preserve all
click-through messages. I'm just saying that each case should be looked at
separately, without general rule in Debian about click-through messages.
So
> The DFSG already prohibits click-through licenses, and likely terms of
> service if they actually constitute a license;
I don't think that the DFSG limits the ways the user may informed by the
software about the applicable license(s).
Regards,
Bart Martens
--
To UNSUBSCRIBE, email
| control system for the package and if it still exists.
|
Other than that, I read good info in your patch, so I think it's a good
addition.
Regards,
Bart Martens
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe&q
oducing the
> package
> +with yourself as the maintainer is considered adversarial and is explicitly
> +disallowed.
> +
You seem to want to prevent hijacking a package via removal and reintroduction.
I don't see how that could be possible, because ftpmaster doesn't remove
uot;author" who ever worked on the "upstream" software.
Some readers may argue that an "upstream contact" may not be an "author" if
he/she maintains the upstream software only by accepting patches created by
others. I suggest to not use the term "author" if we
Hi Russ,
For completeness, since I was involved in the initial debate, here's my opinion
on this bug:
I would welcome the removal of "should name the original authors".
I have currently no strong opinion on the other side-aspects I've read in the
comments so far.
Re
reassign 489135 developers-reference
severity 489135 normal
retitle 489135 developers-reference: uses debian-policy style wording
stop
In my opinion developers-reference should not use must/should/may
wording, because this makes readers confuse developers-reference with
debian-policy.
For examp
On Thu, 2008-07-03 at 10:45 -0700, Russ Allbery wrote:
> Bart Martens <[EMAIL PROTECTED]> writes:
>
> > Package: debian-policy
> > Severity: wishlist
> >
> > Not so long ago the Developer's Reference explained how a repackaged
> > upstream tarball mu
Package: debian-policy
Severity: wishlist
Not so long ago the Developer's Reference explained how a repackaged
upstream tarball must be documented in debian/README.Debian-source. Now
the Developer's Reference states that this must be documented in
debian/copyright.
developers-reference 3.4.0 :
f
d the Apache 2.0 license to the list of common-licenses?
Adding more common licenses in /usr/share/common-licenses makes
debian/copyright files shorter, so yes, that sounds like a good idea.
Regards,
Bart Martens
signature.asc
Description: This is a digitally signed message part
quot;should"
but I may be overlooking a reason to keep "must".)
I agree with you to ask all package maintainers to add a policy
compliant "clean target". I'm not sure about the severity "serious",
see above.
Regards,
Bart Martens
(not yet DD)
signature.asc
Description: This is a digitally signed message part
14 matches
Mail list logo
