Hello Bill,
On Thu, Apr 05 2018, Bill Allombert wrote:
> The standard way is to have a transition period where policy allows
> for both behaviour. This way, debhelper can be updated without
> breaking policy and developers would have a reference for the new
> behaviour.
>
> Then the old behaviour
On Wed, Apr 04, 2018 at 12:00:29PM -0700, Sean Whitton wrote:
> Hello Adrian,
>
> Thank you for your continued effort to get this bug resolved.
>
> On Sat, Mar 10 2018, Adrian Bunk wrote:
>
> >> Please expand on why you think this is the way we have to proceed.
> >
> > you skipped the part of my
Hello,
On Wed, Apr 04 2018, Adrian Bunk wrote:
> This ensures that policy will always be horribly outdated.
Policy is meant to lag behind practice. One of the reasons for this is
that it ensures that no-one feels they have to update Policy before
innovating.
The extent to which it lags is a fu
On Wed, Apr 04, 2018 at 12:00:29PM -0700, Sean Whitton wrote:
> Hello Adrian,
>
> Thank you for your continued effort to get this bug resolved.
>
> On Sat, Mar 10 2018, Adrian Bunk wrote:
>
> >> Please expand on why you think this is the way we have to proceed.
> >
> > you skipped the part of my
Hello Adrian,
Thank you for your continued effort to get this bug resolved.
On Sat, Mar 10 2018, Adrian Bunk wrote:
>> Please expand on why you think this is the way we have to proceed.
>
> you skipped the part of my email with the explanation:
>
> with such a piecemeal approach
> we risk fr
On Sat, Mar 10, 2018 at 11:03:05PM +0200, Adrian Bunk wrote:
>...
> > > I think
> > > the most valuable starting point would to be to standardize on
> > > /usr/share/doc/package/NEWS.gz for the human-readable summary and
> > > explicitly say to never install that as
> > > /usr/share/doc/package/cha
On Tue, Feb 27, 2018 at 10:09:59PM -0700, Sean Whitton wrote:
> Hello,
Hi Sean,
> On Tue, Feb 27 2018, Adrian Bunk wrote:
>
> > Policy should define the naming before dh_installchangelogs should
> > change.
>
> Please expand on why you think this is the way we have to proceed.
you skipped the
Hello,
On Tue, Feb 27 2018, Adrian Bunk wrote:
> Policy should define the naming before dh_installchangelogs should
> change.
Please expand on why you think this is the way we have to proceed.
We try to have Policy reflect changes already in the archive, rather
than the other way around, except
On Sun, Dec 03, 2017 at 05:24:09PM +0100, gregor herrmann wrote:
> On Thu, 30 Nov 2017 20:45:51 -0800, Russ Allbery wrote:
>
> > I think
> > the most valuable starting point would to be to standardize on
> > /usr/share/doc/package/NEWS.gz for the human-readable summary and
> > explicitly say to ne
On Fri, Dec 08, 2017 at 10:29:50AM -0500, Peter Eisentraut wrote:
> On 12/1/17 11:19, Ian Jackson wrote:
> > Is there some reason why exacdt standardisation of the filenames is
> > necessary here ? For most of the uses I can think of, it is OK to
> > look in a handful of files to see which one mig
Peter Eisentraut writes ("Re: Bug#459427: changelog vs. NEWS handling"):
> On 12/1/17 11:19, Ian Jackson wrote:
> > Is there some reason why exacdt standardisation of the filenames is
> > necessary here ? For most of the uses I can think of, it is OK to
> > look in
On 12/1/17 11:19, Ian Jackson wrote:
> Is there some reason why exacdt standardisation of the filenames is
> necessary here ? For most of the uses I can think of, it is OK to
> look in a handful of files to see which one might answer the question.
I wrote the bug originally.
My goal was simply t
On Thu, 30 Nov 2017 20:45:51 -0800, Russ Allbery wrote:
> I think
> the most valuable starting point would to be to standardize on
> /usr/share/doc/package/NEWS.gz for the human-readable summary and
> explicitly say to never install that as
> /usr/share/doc/package/changelog.gz.
That would mean
Hello,
On Thu, Nov 30 2017, Russ Allbery wrote:
> Unfortunately, there's no good way to do this transition without
> making a whole ton of packages buggy, since we're horribly
> inconsistent about how we handle this now. I think that's just
> something we should tackle, and make it very clear th
On Thu, Nov 30, 2017 at 08:45:51PM -0800, Russ Allbery wrote:
> Bill Allombert writes:
>
> > git log might be more useful in some situation and extremly inconvenient
> > in some others (to start with it require network access and cloning the
> > full project history).
>
> A complete changelog is
Russ Allbery writes ("Bug#459427: changelog vs. NEWS handling"):
> Unfortunately, there's no good way to do this transition without making a
> whole ton of packages buggy, since we're horribly inconsistent about how
> we handle this now. I think that's just some
On Thu, Nov 30, 2017 at 09:37:32PM -0800, Russ Allbery wrote:
> This is okay 80% of the time and badly needs manual editing the remaining
> 20% of the time. I personally would never be willing to forgo good
> changelogs in that remaining 20% of the time that can't really be handled
> with commit m
Josh Triplett writes:
> I *do* use apt-listchanges to reach changelogs, and I'm not advocating
> that they not exist; I'm simply arguing that they make it a pain to keep
> a Debian package in git, and that we ought to autogenerate them from git
> log and some care taken in commit messages.
This
On Thu, Nov 30, 2017 at 08:50:11PM -0800, Russ Allbery wrote:
> Jonathan Nieder writes:
> >> I would go so far as to say that I hope we one day stop shipping a
> >> non-generated debian/changelog in source packages, because it incurs
> >> all the same pain.
>
> > I've been trying to make debian/c
Hello Jonathan,
On Thu, Nov 30 2017, Jonathan Nieder wrote:
> I've been trying to make debian/changelog in packages I work on
> user-focused, and no one has complained yet.
>
> I also use NEWS.Debian for notes about incompatibilities that will
> affect sysadmins upgrading.
Yes. If you read the
Jonathan Nieder writes:
> How do you feel about generated changelogs in release tarballs that
> are generated by tools like "git log"?
I think they're a waste of space and effort. The circumstances in which
those are useful are so obscure that I think more harm than good is being
done by making
Bill Allombert writes:
> git log might be more useful in some situation and extremly inconvenient
> in some others (to start with it require network access and cloning the
> full project history).
A complete changelog is often an appreciable percentage of the size of
that full project history.
On Thu, Nov 30, 2017 at 06:56:53PM -0800, Jonathan Nieder wrote:
> Josh Triplett wrote:
> > On Fri, 1 Dec 2017 00:04:20 +0100 Bill Allombert
> > wrote:
>
> >> The fact that some upstream do not bother to ship useful changelog does
> >> not mean that all changelog are useless, and by removing the
Josh Triplett wrote:
> On Fri, 1 Dec 2017 00:04:20 +0100 Bill Allombert wrote:
>> The fact that some upstream do not bother to ship useful changelog does
>> not mean that all changelog are useless, and by removing them we
>> discourage upstream of producing useful changelog.
>
> I sincerely hope
On Fri, 1 Dec 2017 00:04:20 +0100 Bill Allombert wrote:
> Both the content and the name of the upstream changelogs is an upstream
> issue. The fact that a file is named by upstream Changelog instead of
> NEWS does not imply anything on its usefulness. It might even happen
> that NEWS is the real c
On Tue, Nov 28, 2017 at 11:01:08PM -0500, Jeremy Bicha wrote:
> As others have said, running 'git log' is far more useful than a
> complete changelog and in my experience, most projects these days
> outside of GNU don't bother shipping changelogs.
>
> Most of my Debian and Ubuntu work involves GNO
Hi,
gregor herrmann wrote:
> From the Perl world, looking at roughly ~3400 packages I have locally
> cloned:
>
> 28 have a NEWS file (most of them with a Gnome/GTK background), 1
> News, 1 news.
>
> 3368 have a Changes, CHANGES, Changelog, ChangeLog, (and some other
> variations like Change{s,Log
Hello Simon,
On Wed, Nov 29 2017, Simon McVittie wrote:
> How about something like this?
> [...]
Thank you for taking the time to write up patch text for this bug. FWIW
I would second it, however:
I think that debhelper's behaviour needs to be sorted out before we can
change what Policy says.
On Wed, 29 Nov 2017 11:34:21 +, Simon McVittie wrote:
> > Most of my Debian and Ubuntu work involves GNOME packaging. For the
> > most part, GNOME components ships NEWS files which are much more
> > interesting for users or developers to read for highlights of what
> > changed when.
> This is
On Tue, 28 Nov 2017 at 23:01:08 -0500, Jeremy Bicha wrote:
> As others have said, running 'git log' is far more useful than a
> complete changelog and in my experience, most projects these days
> outside of GNU don't bother shipping changelogs.
Many of those projects that do ship a ChangeLog gener
As others have said, running 'git log' is far more useful than a
complete changelog and in my experience, most projects these days
outside of GNU don't bother shipping changelogs.
Most of my Debian and Ubuntu work involves GNOME packaging. For the
most part, GNOME components ships NEWS files which
Yuri D'Elia writes:
> On Mon, Jan 02 2017, Russ Allbery wrote:
>> No matter what we do here, we're going to make a bunch of packages
>> buggy, because the archive is very divided on current best practice.
>> :(
> Buggy in the sense that existing packages wouldn't comply with the new
> rules?
Ri
On Mon, Jan 02 2017, Russ Allbery wrote:
> No matter what we do here, we're going to make a bunch of packages buggy,
> because the archive is very divided on current best practice. :(
Buggy in the sense that existing packages wouldn't comply with the new
rules?
I don't see this as "buggyness", b
Yuri D'Elia writes:
> In fact, I'd rather have a consistent NEWS location, and shift the focus
> to this release summary instead, while not changing the existing
> changelog rules. It's way more consistent with the best practices
> already seen everywhere in source tarballs.
Yeah, this is basica
On Sun, Jan 01 2017, Andreas Henriksson wrote:
> My personal opinion is that a changelog is something where every change
> is guaranteed to be logged. (And that guarantee is basically just saying
> that if it's ever noticed that a change was not logged, that's indeed a
> bug.)
> A NEWS file is some
Hello,
This is one issue I think would be nice to have resolved so will
add my personal opinion below
On Sun, Jan 06, 2008 at 02:55:00PM +0100, Peter Eisentraut wrote:
> Package: debian-policy
> Version: 3.7.3.0
> Severity: normal
>
> There is some lack of clarity in the policy or perhaps so
On Thu, Nov 20, 2014 at 09:21:02PM +0100, Jakub Wilk wrote:
> * Peter Eisentraut , 2008-01-06, 14:55:
> >I think that installing a source-level change list is hardly ever
> >useful for a binary package.
>
> It's normally more useful that no changelog at all. :-)
>
> What I tend to do in my packag
* Peter Eisentraut , 2008-01-06, 14:55:
I think that installing a source-level change list is hardly ever
useful for a binary package.
It's normally more useful that no changelog at all. :-)
What I tend to do in my packages is:
if user-level change list exists:
install it as /usr/shar
On Sun, Jan 06, 2008 at 02:55:00PM +0100, Peter Eisentraut wrote:
> There is some lack of clarity in the policy or perhaps some confusion among
> packagers and thence inconsistencies among packages regarding the handling of
> upstream changelog files. Policy says that upstream changelogs should be
Package: debian-policy
Version: 3.7.3.0
Severity: normal
There is some lack of clarity in the policy or perhaps some confusion among
packagers and thence inconsistencies among packages regarding the handling of
upstream changelog files. Policy says that upstream changelogs should be
installed as
40 matches
Mail list logo