(non-)upstream changelog

[Pietro Battiston]

Hello,
the developers of an app I'm packaging, denemo (www.denemo.org) do not
use (it is there, but not updated since months) the file ChangeLog.

However, they do keep a list of changes, which they published, for the
last release, in their site and on the mailing list, and which content
would be the perfect content for filling a changelog. [0]

Do you suggest me to:
- patch the changelog/introduce a new one, and then install it, or
- in debian/changelog, after "New upstream release", list all of those
changes?

I tend to see the second option as cleaner, but I don't know if ~20
lines of changelog entry for a new upstream release would be considered
too verbose.

thanks in advance for any hint

Pietro

P.S: yes, I may ask them to change their policy... for the next release.

P.P.S: I'm taking care of this package since few months... under
previous maintainer, the upstream ChangeLog was still updated

[0]:
http://lists.gnu.org/archive/html/denemo-devel/2009-11/msg00024.html

[Sandro Tosi-4]

Hi,

2009/11/5 Pietro Battiston <toobaz@...>:

> Hello,
> the developers of an app I'm packaging, denemo (www.denemo.org) do not
> use (it is there, but not updated since months) the file ChangeLog.
>
> However, they do keep a list of changes, which they published, for the
> last release, in their site and on the mailing list, and which content
> would be the perfect content for filling a changelog. [0]
>
> Do you suggest me to:
> - patch the changelog/introduce a new one, and then install it, or
> - in debian/changelog, after "New upstream release", list all of those
> changes?

The only sane solution is to bother upstream until the update the
changelog distributed with the tarball.

> I tend to see the second option as cleaner, but I don't know if ~20
> lines of changelog entry for a new upstream release would be considered
> too verbose.

please don't. That is the *debian* changelog.

> P.S: yes, I may ask them to change their policy... for the next release.

not 'may', just do it.

> P.P.S: I'm taking care of this package since few months... under
> previous maintainer, the upstream ChangeLog was still updated

That's nicer, but I don't think it's worth a hunk in diff.gz (either
as direct change or patch) for this.

Regards,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Pietro Battiston]

Il giorno gio, 05/11/2009 alle 23.20 +0100, Sandro Tosi ha scritto:

> Hi,
>
> 2009/11/5 Pietro Battiston <toobaz@...>:
> > Hello,
> > the developers of an app I'm packaging, denemo (www.denemo.org) do not
> > use (it is there, but not updated since months) the file ChangeLog.
> >
> > However, they do keep a list of changes, which they published, for the
> > last release, in their site and on the mailing list, and which content
> > would be the perfect content for filling a changelog. [0]
> >
> > Do you suggest me to:
> > - patch the changelog/introduce a new one, and then install it, or
> > - in debian/changelog, after "New upstream release", list all of those
> > changes?
>
> The only sane solution is to bother upstream until the update the
> changelog distributed with the tarball.
>
> > I tend to see the second option as cleaner, but I don't know if ~20
> > lines of changelog entry for a new upstream release would be considered
> > too verbose.
>
> please don't. That is the *debian* changelog.
>
> > P.S: yes, I may ask them to change their policy... for the next release.
>
> not 'may', just do it.

OK, done


> > P.P.S: I'm taking care of this package since few months... under
> > previous maintainer, the upstream ChangeLog was still updated
>
> That's nicer, but I don't think it's worth a hunk in diff.gz (either
> as direct change or patch) for this.

In the end, you're suggesting to ship (this version of) the package with
no hint at all about what changed across versions?!

Pietro


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jonathan Nieder]

Hi,

Sandro Tosi wrote:

>> P.P.S: I'm taking care of this package since few months... under
>> previous maintainer, the upstream ChangeLog was still updated
>
> That's nicer, but I don't think it's worth a hunk in diff.gz (either
> as direct change or patch) for this.

What’s stopping one from shipping a debian/changelog.upstream and
using that instead?  If you want to avoid duplicating content from the
old upstream ChangeLog, you can always use "cat" at build time.

On the other hand, I do agree it would be best for upstream to provide
a log with release notes in the distributed tarball, which would
benefit everyone.  If current upstream is not the only author, that
might even be technically required by the GPL (but I am not a lawyer).

Regards,
Jonathan


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russ Allbery-2]

Pietro Battiston <toobaz@...> writes:

> Do you suggest me to:
> - patch the changelog/introduce a new one, and then install it, or
> - in debian/changelog, after "New upstream release", list all of those
> changes?

I always summarize major changes in a new upstream release in
debian/changelog whether upstream provides its own changelog or not.  It
seems polite and I know as a user it makes debian/changelog more useful to
me than a bunch of bare "New upstream release" lines when trying to track
down when something might have changed.

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ben Finney-5]

Russ Allbery <rra@...> writes:

> I always summarize major changes in a new upstream release in
> debian/changelog whether upstream provides its own changelog or not.
> It seems polite and I know as a user it makes debian/changelog more
> useful to me than a bunch of bare "New upstream release" lines when
> trying to track down when something might have changed.

It's especially useful to users when upgrading their systems: we can see
the Debian package changelog (using aptitude) before downloading the
package, but if that just says “New upstream version” with no clue as to
what changed, it's not helpful at that point — and it's at exactly that
point that the user *wants* to know what changed, so we can decide
whether to postpone the upgrade of that package.

--
 \     “I was sad because I had no shoes, until I met a man who had no |
  `\       feet. So I said, ‘Got any shoes you're not using?’” —Steven |
_o__)                                                           Wright |
Ben Finney


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...