I think the close= solution is great. Please file a bug report against
devscripts as soon as you have what you plan operational, so that I can
remove the bug closing functionality from release.
In article <[EMAIL PROTECTED]> you wrote:
: Fabrizio Polacco wrote:
: > But this needs absolutely the op
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
Manoj Srivastava <[EMAIL PROTECTED]> writes:
[ ... ]
> Ok?
Looks good to me, better than the dodgy regex matching certainly.
However there is one caveat, whatever method is used, the script that
parses these things *must* only act on them for .changes files with
"source" in the Architecture
Hi,
>>"Joey" == Joey Hess <[EMAIL PROTECTED]> writes:
Joey> Manoj Srivastava wrote:
>> -%mapkv=(); # for future use
>> +%mapkv=("Closes" => "Bugs_closed"); # for future use
>> $i=100;grep($fieldimps{$_}=$i--,
>> - qw(Source Version Distribution Urgency Maintainer Date Changes));
>> +
Manoj Srivastava wrote:
> -%mapkv=(); # for future use
> +%mapkv=("Closes" => "Bugs_closed"); # for future use
> $i=100;grep($fieldimps{$_}=$i--,
> - qw(Source Version Distribution Urgency Maintainer Date Changes));
> + qw(Source Version Distribution Urgency Maintainer Bugs_close
Fabrizio Polacco wrote:
> But this needs absolutely the opinion of Ian and/or Klee. Not only
> dinstall, but also all other programs that use the changelogfile must be
> modifyed, and back-compatibility have to be studied well.
What other programs? All I know of are dinstall and the perl library
/
Hi,
I just tested changelog.el; it handles things just fine. Most
packages that parse changelog files should handle the additional
keyword just fine (or they are broken and should be fixed). Since the
keywords are already in the specs, backwards compatibility is not a
problem, as no ch
Manoj Srivastava wrote:
>
> Charles> foo (1.0-2) unstable; urgency=low, closes=10002 11930 10109
>
> Right you are. In his infinite wisdom, the designer (Ian?) has already
> considered the possibility of multipe keyword value pairs.
I have to agree that this design seems much far better than th
Santiago Vila Doncel wrote:
> On 29 Oct 1997, Manoj Srivastava wrote:
> > Surely we can come to a consensus on something this trivial?
>
> foo (1.0-2) unstable; urgency=low; closes=10002,11930,10109
>
> seems fine to me (using ";" after "=low").
Surely this is far from being trivial.
That
Manoj Srivastava wrote:
>
> In balance, I think I prefer changing the changelog syntax to
> include closed=, though it raises the spectre of modifying
> changelog.el and dpkg-parsechangelog.
>
Why? That syntax should be interpreted by the installer's scripts on
master, not on the maint
Hi,
>>"Charles" == Charles Briscoe-Smith <[EMAIL PROTECTED]> writes:
Charles> Nooo... Look at this page, in the paragraph about urgency:
Charles>
http://www.debian.org/doc/manuals/packaging-manual/ch-sourcepkg.html#s-dpkgchangelog
Charles> Closes would be a keyword, like urgency, and can be ha
Charles Briscoe-Smith wrote:
> Nooo... Look at this page, in the paragraph about urgency:
>
> http://www.debian.org/doc/manuals/packaging-manual/ch-sourcepkg.html#s-dpkgchangelog
>
> Closes would be a keyword, like urgency, and can be handled by the current
> keyword=value system, just like urge
Santiago Vila Doncel wrote:
> Another idea: In addition to "hello_1.3-14_i386.changes" we could have
> "hello_1.3-14_i386.closes", following a very simple syntax:
>
> 1234
> 5678
> 9012
If we use this, you don't get the benefit of seeing the bugs that were
closed by each release, in the changelog
Fabrizio Polacco wrote:
> Right, and I agree.
> While we are discussing the rexpr to be used, I'd ask to please consider
> using:
> /close[s]? \s* = \s* (?:bug)? \s* \# (\d+)/ix
>
> Matches:
> close=#1234
> close =
> #97531
> Closes = Bug#5678 and also close=#87
In article <[EMAIL PROTECTED]> you write:
>
>foo (1.0-2) unstable; urgency=low; closes=10002,11930,10109
>
>seems fine to me (using ";" after "=low").
Nooo... Look at this page, in the paragraph about urgency:
http://www.debian.org/doc/manuals/packaging-manual/ch-sourcepkg.html#s-dpkgchangelog
Hi,
>>"Santiago" == Santiago Vila Doncel <[EMAIL PROTECTED]> writes:
Santiago> foo (1.0-2) unstable; urgency=low; closes=10002,11930,10109
Santiago> seems fine to me (using ";" after "=low").
Seconded.
manoj
--
You should encourage yourself, yourself. You should restrain
your
-BEGIN PGP SIGNED MESSAGE-
On 29 Oct 1997, Manoj Srivastava wrote:
> [...]
>
> Surely we can come to a consensus on something this trivial?
Ok,
foo (1.0-2) unstable; urgency=low; closes=10002,11930,10109
seems fine to me (using ";" after "=low").
-BEGIN PGP SIGNATURE-
V
Hi,
>>"Santiago" == Santiago Vila Doncel <[EMAIL PROTECTED]> writes:
Santiago> I don't see very elegant to modify changelog syntax.
Ulp. I thought it was very elegant ...
Santiago> Another idea: In addition to "hello_1.3-14_i386.changes" we
Santiago> could have "hello_1.3-14_i386.closes"
-BEGIN PGP SIGNED MESSAGE-
I don't see very elegant to modify changelog syntax.
Another idea: In addition to "hello_1.3-14_i386.changes" we could have
"hello_1.3-14_i386.closes", following a very simple syntax:
1234
5678
9012
etc.
This way everybody could use their favourite parsing al
Hi,
>>"Rob" == Rob Browning <[EMAIL PROTECTED]> writes:
Rob> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> I do not quite understand the X-debian-Closes proposal. When do I
>> insert this header? into what?
Rob> This was put forward as one option. What they were talking about
Rob> was an opti
Rob Browning wrote:
> I happen to think
> that the changelog closes= field is the best thing suggested so far.
>
Right, and I agree.
While we are discussing the rexpr to be used, I'd ask to please consider
using:
/close[s]? \s* = \s* (?:bug)? \s* \# (\d+)/ix
without forcing use of upper
Joey Hess <[EMAIL PROTECTED]> writes:
> Hmm, this is different than the idea of adding them to the changelog and
> having Guy's installer scripts close the bugs. If this X-CLose header is
> used, the responsibility for closing bugs is still left up to the developer.
> Part of the reason for having
Rob Browning wrote:
> This was put forward as one option. What they were talking about was
> an optional mail header that would be in the message making the
> announcement, and would be picked up and processed by a smart list
> handler. See my header above for a silly example. (You'll probably
>
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> I do not quite understand the X-debian-Closes proposal. When
> do I insert this header? into what?
This was put forward as one option. What they were talking about was
an optional mail header that would be in the message making the
announcem
Hi,
Come to think of it, I too would like to say I like the
closes= statement in the changelog; There can then be a log of what
bugs were clsed when.
I do not quite understand the X-debian-Closes proposal. When
do I insert this header? into what?
manoj
--
"Sometimes
Johnie Ingram <[EMAIL PROTECTED]> writes:
> I prefer the current usage of #(\d+) -- a bug that is referenced but
> not to be closed can bet called just \d+, or Bug \d+, and the script
> will ignore it just as "release" currently does.
Not a good idea. What if I need to say:
* Partial fix for
Hi,
>>"Christoph" == Christoph Lameter <[EMAIL PROTECTED]> writes:
Christoph> Very good idea. Maybe that should be the ONLY way bug
Christoph> reports could be closed? That way we have an insurance that
Christoph> bug reports are only closed by the maintainer.
Hahaha. Very funny. I like t
On Mon, 27 Oct 1997, Christoph Lameter wrote:
> Very good idea. Maybe that should be the ONLY way bug reports could be
> closed? That way we have an insurance that bug reports are only closed
> by the maintainer.
Please tell me you're being sarcastic here. There are plenty of bugs that
aren't b
Very good idea. Maybe that should be the ONLY way bug reports could be closed?
That way we have an
insurance that bug reports are only closed by the maintainer.
In article <[EMAIL PROTECTED]> you wrote:
: Andreas Jellinghaus writes:
: > > Topic 4: Announcing new packages before uploading them
:
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> >> Changes: section. So Guys script should look for #(\d+) and
> >> close $1 after proceeding (speaking in Perl).
>
> Andreas> lets use "\(close #(\d+)\)", some people might make a note
> Andreas> related to a bug not yet fixed.
>
> Johnie> I prefe
-BEGIN PGP SIGNED MESSAGE-
On Mon, 27 Oct 1997, Joey Hess wrote:
> I don't like overloading the changelog like this (no, I don't use release).
> How about extending the changelog format so we have a field for closed bugs?
> Something like:
>
> foo (1.0-2) unstable; urgency=low closes=100
Manoj Srivastava wrote:
> Maybe a slightly stricter syntax for closing bugs, so I may
> mention things like "This is similar to Bug#12345 on package xyz. We
> are still lokking for a solution".
>
> Maybe the check should eb for "This closes Bug#*** BUG#***"
> (concatenatnig the line
Hi,
>>"Johnie" == Johnie Ingram <[EMAIL PROTECTED]> writes:
Johnie> "Andreas" == Andreas Jellinghaus <[EMAIL PROTECTED]> writes:
>> Changes: section. So Guys script should look for #(\d+) and close
>> $1 after proceeding (speaking in Perl).
Andreas> lets use "\(close #(\d+)\)", some people might
"Andreas" == Andreas Jellinghaus <[EMAIL PROTECTED]> writes:
>> Changes: section. So Guys script should look for #(\d+) and close
>> $1 after proceeding (speaking in Perl).
Andreas> lets use "\(close #(\d+)\)", some people might make a note
Andreas> related to a bug not yet fixed.
I prefer the
> > i will like an automatic method to close bugs.
>
> Let's take a look at the .changes files. Normally all information
> is covered there. Normally closed bugs are mentioned in the
> Changes: section. So Guys script should look for #(\d+) and
> close $1 after proceeding (speaking in Perl).
l
Hi,
>>"Martin" == Martin Schulze <[EMAIL PROTECTED]> writes:
>> i will like an automatic method to close bugs.
Martin> Let's take a look at the .changes files. Normally all
Martin> information is covered there. Normally closed bugs are
Martin> mentioned in the Changes: section. So Guys script
Andreas Jellinghaus writes:
> > > > Topic 4: Announcing new packages before uploading them
> > >
> > > we should stop announcing and let a script on master do this.
> >
> > And according to James' oppionion this script should also close
> > the referring bugs - opposite to closing bugs while upl
On Sun 26 Oct 1997, Martin Schulze wrote:
> Andreas Jellinghaus writes:
>
> > > Topic 4: Announcing new packages before uploading them
> >
> > we should stop announcing and let a script on master do this.
>
> And according to James' oppionion this script should also close
> the referring bugs -
Martin Schulze wrote:
>
> Andreas Jellinghaus writes:
>
> > we should stop announcing and let a script on master do this.
>
> And according to James' oppionion this script should also close
> the referring bugs - opposite to closing bugs while uploading.
>
Is this script run before or after mo
Andreas Jellinghaus writes:
> > Topic 4: Announcing new packages before uploading them
>
> we should stop announcing and let a script on master do this.
And according to James' oppionion this script should also close
the referring bugs - opposite to closing bugs while uploading.
Regards
Hi,
>>"Andreas" == Andreas Jellinghaus <[EMAIL PROTECTED]> writes:
Andreas> On Thu 23 Oct 1997, Christian Schwarz wrote:
>> Topic 4: Announcing new packages before uploading them
Andreas> we should stop announcing and let a script on master do this.
This is a separate issue. Maybe the p
On Thu 23 Oct 1997, Christian Schwarz wrote:
>
> Topic 4: Announcing new packages before uploading them
we should stop announcing and let a script on master do this.
andreas
Topic 4: Announcing new packages before uploading them
STATE: APPROVAL
According to current policy, every upload of a new package to the archive
has to be announced on debian-devel _before_ the package is uploaded to
the master site. However, must developers do not know this yet. That's why
it s
43 matches
Mail list logo
