On Fri, 20 Feb 1998, Christian Schwarz wrotee, while discussing the
proposed (and agreed upon) changes to dpkg-genchanges and dinstall to
make the closing of bugs etc. run more smoothly:
Another suggestion was to change the Maintainer: field to Developer:,
Uploader: or whatever, since this
On Thu, 3 Dec 1998, Julian Gilbey wrote:
On Fri, 20 Feb 1998, Christian Schwarz wrotee, while discussing the
proposed (and agreed upon) changes to dpkg-genchanges and dinstall to
make the closing of bugs etc. run more smoothly:
Another suggestion was to change the Maintainer: field to
Christian == Christian Schwarz [EMAIL PROTECTED] writes:
Which term do the others prefer?
How about:
* file.c (function): The change I made. [Bug#]
* file2: Another change here. [Bug#]
--
mailto:[EMAIL PROTECTED] (Karl M. Hegbloom)
http://www.inetarena.com/~karlheg
[EMAIL PROTECTED] (Richard Braakman) writes:
Should the installer check, before closing a bug, if that bug was
reported to the source package (or one of its binary packages) that
closes it?
The installer will CC the bug closes to the maintainer, so she can
confirm that the right ones were
[EMAIL PROTECTED] (Guy Maor) wrote on 02.02.98 in [EMAIL PROTECTED]:
Ian makes a good point that we shouldn't use different words to refer
to the same action. So I'd go for closes rather than fixes.
I just realized, we're talking about adding a state fixed to the bug
system. Now if we'd
Christian Schwarz wrote:
7.) [For source uploads only]
Close bug reports that are fixed with this package upload
(see below for details).
I don't know if this has been considered yet:
It is pretty easy to close the wrong bug by mistake. Reporting such a
mistake
On Thu, 5 Feb 1998, Richard Braakman wrote:
Christian Schwarz wrote:
7.) [For source uploads only]
Close bug reports that are fixed with this package upload
(see below for details).
I don't know if this has been considered yet:
It is pretty easy to close
Ian Jackson [EMAIL PROTECTED] writes:
There are two reasons I can think of at the moment for putting the
parsing into dpkg-parsechangelog.
Since Mike is planning to release a new dpkg very soon anyway, someone
can just send him a patch and he'll include it.
Guy
Ian makes a good point that we shouldn't use different words to refer
to the same action. So I'd go for closes rather than fixes.
Regarding the re to use, I don't think we've relaxed it to such a
degree that people will close things by accident. The only difference
is that the original allows
Guy:
Regarding the re to use, I don't think we've relaxed it to such a
degree that people will close things by accident. The only difference
is that the original allows white space and ignores case.
Err, yes. I withdraw my objection.
Ian.
On Tue, 3 Feb 1998 [EMAIL PROTECTED] wrote:
[snip]
If Ian wants anyway to modify dpkg-parsechangelog or dpkg-genchanges,
then the proposal (already discarded) to have a pre-parsing at build
time, revealing the bug numbers to be closed, could be re-considered.
I don't think it's necessary to
On Tue, 3 Feb 1998 [EMAIL PROTECTED] wrote:
[snip]
If Ian wants anyway to modify dpkg-parsechangelog or
dpkg-genchanges,
then the proposal (already discarded) to have a pre-parsing at build
time, revealing the bug numbers to be closed, could be
re-considered.
I don't think it's
Christian Schwarz:
* Changed `closes' and `closed' term into `fixes'
(This has been suggested by a few people. Please tell me if `closes'
would still be preferred.)
I would prefer `close', `closes' OR `closed' (but obviously only one
of them). This is the term used by the bug
On Mon, 2 Feb 1998, Ian Jackson wrote:
Christian Schwarz:
* Changed `closes' and `closed' term into `fixes'
(This has been suggested by a few people. Please tell me if `closes'
would still be preferred.)
I would prefer `close', `closes' OR `closed' (but obviously only
The point of choosing `fixes' was that it's probably much easier to
understand for non-Debian people: bugs can only be `fixed' (not `closed')
but bug reports need to be `closed' :-)
Yes, but it's possible to close the bug report without having fixed the
bug reported. An example would be an
On Mon, Feb 02, 1998 at 06:34:57PM +0100, Christian Schwarz wrote:
On Mon, 2 Feb 1998, Ian Jackson wrote:
I would prefer `close', `closes' OR `closed' (but obviously only one
Anyways, we had this discussion a few times already. As I remember from
last time, you (Ian) were the only one who
On 15 Jan 1998, Guy Maor wrote:
Christian Schwarz [EMAIL PROTECTED] writes:
3.) [check for new packages every ten minutes]
Check if package upload was complete and the files are correct
(i.e. check PGP signature, MD5 sums, correct .changes file, etc.)
Christian Schwarz [EMAIL PROTECTED] writes:
The idea behind this is the following: Currently, the developer announces
the upload after having the file uploaded to Incoming. Since dinstall only
runs once a day there is a slight chance that a severe bug is detected and
fixed before dinstall
Christian Schwarz [EMAIL PROTECTED] writes:
3.) [check for new packages every ten minutes]
Check if package upload was complete and the files are correct
(i.e. check PGP signature, MD5 sums, correct .changes file, etc.)
If there is an error send mail to
On 13-Jan-1998 23:34:29, Christian Schwarz [EMAIL PROTECTED] wrote:
1. With the current proposal, bug reports are only closed for source
uploads. (That's important since we don't want our bugs being closed
several times, once for each architecture :-)
I'm sorry, I missed the
[EMAIL PROTECTED] (Christian Schwarz) wrote on 13.01.98 in [EMAIL PROTECTED]:
So, if a package upload fixes some bugs, the maintainer should include
some tags in the debian/changelog file that use the following syntax
(Perl regexp syntax, case-insensitive):
[This mail is part of Debian Policy Weekly issue #5]
Topic 12: New upload procedure
STATE: APPROVAL
We've developed a new upload procedure on debian-policy and debian-devel
some time ago (in Nov 97, I think). The major change is that bug reports are
closed by a script on master after the
22 matches
Mail list logo
