Re: Policy Weekly Issue #4/4: Announcing new packages before uploading them
Manoj Srivastava wrote:
>
> Technically, there is one right solution; and that is to use
> the keywords capability of the Debian changelog format.
Right. As I said, it's a polite design. I simply wasn't aware that the
"reserved for future use" was already implemented in the code, and not
simply a wish in the docs.
I hadn't seen that nice code before (yes, really nice: I have to agree
with Ian about the "correct" rate complexity/readability of the code).
I simply missed the documents that explained all this (maybe they are
new?)
Having seen that this is still working now, I retract my proposal (no
more need to invent some syntax: why were we discussing it BTW?)
About the code that still needs to be written, it is quite the same as
before: in the "dinstall" to effectively close the bugs (correct me if
I'm wrong, please: dinstall is the program used by Guy to move packages
from Incoming to the ftp hierarchy, isn't it? Where is it possible to
find it?)
> As to how the bugs are closed, there is no reason that the
> control interface be used; dinstall can use the
> xxx-closed@bugs.debian.org just like release does now (send in the
> changes file to close the report).
I don't know how "release" closes bugs actually. As I understand it does
this on the maintainer's machine, while dinstall should do this from
master.
> xxx-closed@bugs.debian.org
I think you meant XXX-done@ or XXX-close@ (I prefer the former, because
the latter is an alias).
This is exactly what I proposed and therefore I agree. :-)
I would also like that the message that dinstall builds could have the
.changes file attached. This is because the original submitters of the
bugs will receive the messages sent to XXX-done@ and this messege would
be better contain the reason for closing the bug.
I suppose you agree with this, as it is our current policy.
> Ok? Oh, yes, it would be nice if the dpkg maintainers did say
> something about the ease of implementation, since us munchkins can't
> say anything authoritative.
Yes, all our talking is waporware, untill their approval :-)
>
> ============================Changelog file===========================
> make (3.76.1-3) unstable; urgency=low, closes=1200 1234 23489
>
> * With Stellar help from Stephen Zander <srz@mckesson.com>, changed
> the aclocal.m4 file (already present in the upstream sources) to
> override the function that checks for libelf. This should now not
> create a spurious dependency on libelfg0 even if the gremlins
> cause automake to be run to recreate configure.
>
> -- Manoj Srivastava <srivasta@debian.org> Wed, 29 Oct 1997 14:22:37
What we lose in this way is perhaps the association between the entry
and the number of the bug. I usually always add the bugnumber as a
reference to each entry (when appropriate), and thus there could be a
little duplication of work for the maintainer. It's not a problem for
me, but it would be better to suggest maintainers to check the
correctness between the list of closes= and each entry in the changelog
description (Nice, it seems that I could have find at least a use for my
parser row, isn't it? :-)
Fabrizio
--
| fpolacco@icenet.fi fpolacco@debian.org fpolacco@pluto.linux.it
| Pluto Leader - Debian Developer & Happy Debian 1.3.1 User - vi-holic
| 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E
> Just because Red Hat do it doesn't mean it's a good idea. [Ian J.]
Reply to: