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

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]



Dear Nicholas,

On Sun, Jan 15, 2017 at 04:51:24PM -0700, Nicholas D Steeves wrote:
> On Sun, Jan 15, 2017 at 07:45:18AM -0700, Sean Whitton wrote:
> > I found some more errors in the copyright file.  Rather than go back and
> > forth once again, I fixed them in our team git repository.  I set the
> > changelog back to UNRELEASED: if you are okay with the changes, please
> > `dch -r`, commit and push, and I will upload.
> 
> Why did you remove 2001 from Eric Marsen's cgi.el copyright entry when
> the file is time stamped <2001-08-24 emarsden>?  

Ah, sorry.

> For httpd.el, I agree that "2001, 2003" is more accurate, but is it
> allowed?  In the past, when I've submitted patches to this effect the
> maintainer of the package changed the lines to something like
> "2001-2003", even though the VCS and copyright embedded in the file
> specified discreet years rather than a range...which led me to believe
> that a discreet range is unacceptable.

A discrete range is fine.

> Ah!  Yes, this is the spec that addresses my question to #3.  That
> said, in the past some of my other work on d/copyright has been said
> to be "worse than useless" even though it adhered to the spec, and
> even though it seemed to reflect what I saw reading the packages
> COPYING file, in addition to spending a while reading VCS commits for
> stuff I wasn't sure about.  This has led me to wonder about the tribal
> rules that are not in the spec...

Could you give me an example of a rule like that?

> Would you please check to see if my latest commit to d/copyright is
> ok?  It's what makes the most sense to me.  As far as I can tell, it
> might be problematic because it infers that Eric Marsden changed
> cgi.el in 2003.  If it's problematic I'll revert it, then dch -r.

No, it doesn't actually imply that Marsden changed that file in 2004
(the spec does explain this!).

Go ahead and `dch -r`!

-- 
Sean Whitton

Attachment: signature.asc
Description: PGP signature


Reply to: