Hi all, sorry for the late reply.
On Tue, Mar 03, 2009 at 09:03:22PM +0100, Luca Capello wrote:
> > I unfinalize to add something, but finalize using distribution UNRELEASED
> > to save the work in CVS. I only set the distribution to unstable when
> > ready for an actual upload.
>
> I do not remember having seen a lot of people having the same workflow
> as me: I do not finalize anything except before the final version which
> will be either uploaded to Debian or given out for tests.
You do _not_? Is that correct?
Then the problem can be moot, but:
(1) your work-flow is used in a team, right? I had the impression it
was a team best-practice;
(2) the current name "finalize" vs "unfinalize" encourage your
work-flow, IMO
> I think that the problem is not strictly-related to dpkg-dev-el, but it
> is a more general one and AFAIK there is no strong (i.e., a must in the
> Debian Policy) convention on this matter.
Maybe, but note that the policy speaks about packages appearing in the
archive and says nothing about the state they should have during the
development cycle, e.g., while residing on a VCS. So good luck with
bringing this into Policy :-) Even though this is not specific to
dpkg-dev-el, fixing it there has the potential of zeroing the problem,
because the other major tool used to fiddle with changelog (dch) is
not affected by the "issue".
> >> 2) unfinalized entries are not properly parseable by
> >> dpkg-parsechangelog (which indeed complains) and strictly speacking
> >> do not adhere to the debian/changelog syntax
>
> As Stefano already knows, I disagree here: IMHO, since we are talking
> about a working version, there is no "real" debian/changelog.
Fair enough, we disagree on that.
Nevertheless in Debian we are de facto pushing for putting packages'
VCSs into use. We have debcheckout which is explicitly meant, and
actually quite widespread, to let brave users look for patches we are
using in VCSs. Having "unproper" packages there *will* affect our
users.
I'm sure we all agree that if you taking a package from a VCS you are
taking risks. But small details like this one are breakages which seem
to be introduced on purpose ("broken by design" if you want), with no
advantage which is clear to me.
> >> - keep author name / timestamp after -- and use "UNRELEASED" as the
> >> distribution for unfinalized changelog entries. Also, do not touch
> >> the timestamp until an entry is finalized (which avoids useless VCS
> >> commit diffs)
> I disagree on the second part of this solution: if an entry must be
> finalized, then the timestamp should reflect it. Yes, this brings
> useless VCS commit diffs, but I really think that if the timestamp would
> not be updated, then there is no difference between having an entry
> finalized or not.
Fair enough, I've no strong opinion on this.
Still, if this gets implemented, it would make sense to have this
detail customizable.
> >> - upon finalization: fix UNRELEASED and update the timestamp
> IIRC lintian should whine if distributions is UNRELEASED.
It does, but the proposal still stands.
In my vision (which is not necessarily the right one) you finalize
when you want to upload: better to remove UNRELEASED by default then
delaying issue discovery at the lintian step.
> You are right, but if the previous Vim maintainer moved to Emacs,
> maybe this will change in the future ;-)
LOL
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
