On Tue, Feb 14, 2017, at 19:42, Ian Jackson wrote:
> Simon McVittie writes ("Re: changelog practice, unfinalised vs UNRELEASED
> vs ~version"):
> > On Mon, 13 Feb 2017 at 09:42:32 +1100, Ben Finney wrote:
> > > I don't see how this complaint is any differe
Hi!
On Thu, 2017-02-23 at 17:57:33 +, Ian Jackson wrote:
> Simon McVittie writes ("Re: changelog practice, unfinalised vs UNRELEASED vs
> ~version"):
> > On Thu, 23 Feb 2017 at 12:53:40 +, Ian Jackson wrote:
> > > We could decorate the suite inst
Simon McVittie writes ("Re: changelog practice, unfinalised vs UNRELEASED vs
~version"):
> On Thu, 23 Feb 2017 at 12:53:40 +, Ian Jackson wrote:
> > We could decorate the suite instead, but that does not have any
> > effect on generated binaries.
>
> It does
On 2017-02-14 23:01 +, Ian Jackson wrote:
> Wookey writes ("Re: changelog practice, unfinalised vs UNRELEASED vs
> ~version"):
> > I'd be happier if I didn't have to deal with 'UNRELEASED' at all
> > unless I actually wanted to, so I'
On Thu, 23 Feb 2017 at 12:53:40 +, Ian Jackson wrote:
> We could
> decorate the suite instead, but that does not have any effect on
> generated binaries.
It does have an effect on the changelog inside the source and binary
packages, and on the changes file (which is precisely the signed
instru
Guido Günther writes ("Re: changelog practice, unfinalised vs UNRELEASED vs
~version"):
> On Mon, Feb 20, 2017 at 08:05:02PM +, Ian Jackson wrote:
> > I think the asnwer to this is the same as that I gave to Wookey who
> > mentioned a workflow involving vcs tags.
On Mon, Feb 20, 2017 at 08:05:02PM +, Ian Jackson wrote:
> Guido Günther writes ("Re: changelog practice, unfinalised vs UNRELEASED vs
> ~version"):
> > On Sun, Feb 12, 2017 at 12:48:35PM +, Ian Jackson wrote:
> > > We do not seem to have a coherent approac
Guido Günther writes ("Re: changelog practice, unfinalised vs UNRELEASED vs
~version"):
> On Sun, Feb 12, 2017 at 12:48:35PM +, Ian Jackson wrote:
> > We do not seem to have a coherent approach to how to handle
> > debian/changelog in trees (eg, vcs branches) which
Hi Ian,
On Sun, Feb 12, 2017 at 12:48:35PM +, Ian Jackson wrote:
> We do not seem to have a coherent approach to how to handle
> debian/changelog in trees (eg, vcs branches) which are not yet ready
> for upload.
>
> See below two examples of things done differently.
> The questions are:
>
> Q
On Sun, Feb 12, 2017 at 02:11:12PM +, Simon McVittie wrote:
[..snip..]
> with a middle ground that is less theoretically defensible than
> either, but pragmatically quite useful:
>
> * Mostly write the changelog later, as in the second model.
> Periodically summarize the changelog so far (si
Wookey writes ("Re: changelog practice, unfinalised vs UNRELEASED vs ~version"):
> I'd be happier if I didn't have to deal with 'UNRELEASED' at all
> unless I actually wanted to, so I'm not at all keen on your suggestion
> of making it mandatory.
Sean Whitton writes ("Re: changelog practice, unfinalised vs UNRELEASED vs
~version"):
> On Sun, Feb 12, 2017 at 12:48:35PM +, Ian Jackson wrote:
> > Q1. Should the suite in the changelog entry be UNRELEASED,
> > or the suite at which the vcs branch is ta
Simon McVittie writes ("Re: changelog practice, unfinalised vs UNRELEASED vs
~version"):
> On Mon, 13 Feb 2017 at 09:42:32 +1100, Ben Finney wrote:
> > I don't see how this complaint is any different from the need to merge,
> > for example, changes to API doc
Simon McVittie writes ("Re: changelog practice, unfinalised vs UNRELEASED vs
~version"):
> If I'm understanding correctly, your motivation to do so is that you
> have a strong belief that building a Debian source package with `debuild`
> or similar, directly from a VCS
On February 12, 2017 3:37:59 PM EST, Luca Capello wrote:
>Hi there,
>
>On Sun, 12 Feb 2017 14:11:12 +, Simon McVittie wrote:
>> On Sun, 12 Feb 2017 at 12:48:35 +, Ian Jackson wrote:
>> > What do people think ?
...
>
>> I don't think Debian would be as
>> large or successful a project as
Sean Whitton dijo [Mon, Feb 13, 2017 at 04:33:15PM -0700]:
> > So, my idea was, in short: Thinking in a post-Buster world, do we even
> > need the finalized line? I mean, take a look at debian/changes. The
> > archive handling tools do get both «Date» and «Changed-By» fields,
> > which reflect when
Sean Whitton dijo [Mon, Feb 13, 2017 at 04:35:19PM -0700]:
> > (Of course, the signoff line in the changelog is redundant with
> > the GPG signature, which is what actually matters but isn't at all
> > user-visible...)
>
> It's not redundant for sponsored uploads where the sponsor is not a
> membe
Hello Simon,
On Mon, Feb 13, 2017 at 05:14:17PM +, Simon McVittie wrote:
> (Of course, the signoff line in the changelog is redundant with
> the GPG signature, which is what actually matters but isn't at all
> user-visible...)
It's not redundant for sponsored uploads where the sponsor is not
On Mon, Feb 13, 2017 at 10:53:18AM -0600, Gunnar Wolf wrote:
> So, my idea was, in short: Thinking in a post-Buster world, do we even
> need the finalized line? I mean, take a look at debian/changes. The
> archive handling tools do get both «Date» and «Changed-By» fields,
> which reflect when the p
On Mon, Feb 13, 2017 at 10:53:18AM -0600, Gunnar Wolf wrote:
> So, my idea was, in short: Thinking in a post-Buster world, do we even
> need the finalized line? I mean, take a look at debian/changes. The
the changes file(s) is/are not part of the source packages and we are using
the last date in
On Mon, 13 Feb 2017 at 10:53:18 -0600, Gunnar Wolf wrote:
> Interesting discussion. This (and not particularly your message, but
> this whole thread even leads me to questioning: Does our "finalized"
> changelog lines make *any* sense nowadays?
In the actual upload to the archive (as opposed to th
Simon McVittie dijo [Sun, Feb 12, 2017 at 02:11:12PM +]:
> On Sun, 12 Feb 2017 at 12:48:35 +, Ian Jackson wrote:
> > What do people think ?
>
> I think you're the only person I've ever seen using unfinalized
> changelog entries for Debian packages.
>
> If I'm understanding correctly, your
Ben Finney writes:
> Russ Allbery writes:
>> I really want something that will pass Lintian completely but that
>> dput will refuse to upload, which is what UNRELEASED currently
>> accomplishes.
> Wookey writes:
>> 1. I really dislike dch's enthusiasm for putting in 'UNRELEASED'. It
>> gives
Simon McVittie writes:
> On Mon, 13 Feb 2017 at 09:42:32 +1100, Ben Finney wrote:
> > I'm in agreement with Ian that the “write the documentation
> > (including the changelog) along with the change it describes”
> > workflow should have full support from our tools.
>
> Are you making the stronger
On Mon, 13 Feb 2017 at 09:42:32 +1100, Ben Finney wrote:
> Simon McVittie writes:
> > This works fine if every commit is final and immutable and is sent
> > directly to the master VCS immediately, but works very poorly if you
> > are proposing commits for someone else to merge at a later dat
Russ Allbery writes:
> I really want something that will pass Lintian completely but that
> dput will refuse to upload, which is what UNRELEASED currently
> accomplishes.
Wookey writes:
> 1. I really dislike dch's enthusiasm for putting in 'UNRELEASED'. It
> gives me nothing I wanted, and just
Simon McVittie writes:
> I think you're the only person I've ever seen using unfinalized
> changelog entries for Debian packages.
I think the fact you don't know we're using this workflow isn't very
informative :-)
> Broadly, the two extremes of workflows for Debian packages' changelogs
> maint
Hi there,
On Sun, 12 Feb 2017 14:11:12 +, Simon McVittie wrote:
> On Sun, 12 Feb 2017 at 12:48:35 +, Ian Jackson wrote:
> > What do people think ?
>
> I think you're the only person I've ever seen using unfinalized
> changelog entries for Debian packages.
FWIW, I am another user of this
On Sun, Feb 12, 2017 at 06:34:26PM +, Wookey wrote:
> But the
> UNRELEASED/'dch -r' thing pisses me off on a daily basis, and this
> seemed like the time to point out that some of us don't find it all
> helpful. From that POV, moving it from suite to version would
> definitely be less annoying.
On 2017-02-12 12:48 +, Ian Jackson wrote:
> We do not seem to have a coherent approach to how to handle
> debian/changelog in trees (eg, vcs branches) which are not yet ready
> for upload.
>
> See below two examples of things done differently.
> The questions are:
>
> Q1. Should the suite in
Ian Jackson writes:
> Q2: The information in the trailer line of the changelog entry in a new
> branch is not meaningful. Depending on the vcs etc. in use, it can
> cause pointless merge conflicts. Often the information is quite wrong:
> for example, a date which is earlier than the most recent
On Sun, Feb 12, 2017 at 02:11:12PM +, Simon McVittie wrote:
> On Sun, 12 Feb 2017 at 12:48:35 +, Ian Jackson wrote:
> > Q1. Should the suite in the changelog entry be UNRELEASED,
> > or the suite at which the vcs branch is targeted ?
>
> If you're trying to change common practice (bein
Hello Ian,
On Sun, Feb 12, 2017 at 12:48:35PM +, Ian Jackson wrote:
> Q1. Should the suite in the changelog entry be UNRELEASED,
> or the suite at which the vcs branch is targeted ?
> [...]
> Q1: Replacing the suite with "UNRELEASED" means that it is not
> possible to distinguish a branch
On Sun, Feb 12, 2017 at 12:48:35PM +, Ian Jackson wrote:
> We do not seem to have a coherent approach to how to handle
> debian/changelog in trees (eg, vcs branches) which are not yet ready
> for upload.
True. We also don't have one recommended way how to write debian/rules, how to
build pack
On Sun, 12 Feb 2017 at 12:48:35 +, Ian Jackson wrote:
> What do people think ?
I think you're the only person I've ever seen using unfinalized
changelog entries for Debian packages.
If I'm understanding correctly, your motivation to do so is that you
have a strong belief that building a Debia
We do not seem to have a coherent approach to how to handle
debian/changelog in trees (eg, vcs branches) which are not yet ready
for upload.
See below two examples of things done differently.
The questions are:
Q1. Should the suite in the changelog entry be UNRELEASED,
or the suite at which t
36 matches
Mail list logo
