[Python-Dev] Failed issue tracker submission
The node specified by the designator in the subject of your message
("715365") does not exist.
Subject was: "[issue715365]"
Mail Gateway Help
=
Incoming messages are examined for multiple parts:
. In a multipart/mixed message or part, each subpart is extracted and
examined. The text/plain subparts are assembled to form the textual
body of the message, to be stored in the file associated with a "msg"
class node. Any parts of other types are each stored in separate files
and given "file" class nodes that are linked to the "msg" node.
. In a multipart/alternative message or part, we look for a text/plain
subpart and ignore the other parts.
. A message/rfc822 is treated similar tomultipart/mixed (except for
special handling of the first text part) if unpack_rfc822 is set in
the mailgw config section.
Summary
---
The "summary" property on message nodes is taken from the first non-quoting
section in the message body. The message body is divided into sections by
blank lines. Sections where the second and all subsequent lines begin with
a ">" or "|" character are considered "quoting sections". The first line of
the first non-quoting section becomes the summary of the message.
Addresses
-
All of the addresses in the To: and Cc: headers of the incoming message are
looked up among the user nodes, and the corresponding users are placed in
the "recipients" property on the new "msg" node. The address in the From:
header similarly determines the "author" property of the new "msg"
node. The default handling for addresses that don't have corresponding
users is to create new users with no passwords and a username equal to the
address. (The web interface does not permit logins for users with no
passwords.) If we prefer to reject mail from outside sources, we can simply
register an auditor on the "user" class that prevents the creation of user
nodes with no passwords.
Actions
---
The subject line of the incoming message is examined to determine whether
the message is an attempt to create a new item or to discuss an existing
item. A designator enclosed in square brackets is sought as the first thing
on the subject line (after skipping any "Fwd:" or "Re:" prefixes).
If an item designator (class name and id number) is found there, the newly
created "msg" node is added to the "messages" property for that item, and
any new "file" nodes are added to the "files" property for the item.
If just an item class name is found there, we attempt to create a new item
of that class with its "messages" property initialized to contain the new
"msg" node and its "files" property initialized to contain any new "file"
nodes.
Triggers
Both cases may trigger detectors (in the first case we are calling the
set() method to add the message to the item's spool; in the second case we
are calling the create() method to create a new node). If an auditor raises
an exception, the original message is bounced back to the sender with the
explanatory message given in the exception.
Return-Path:
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from mail.python.org (mail.python.org [IPv6:2001:888:2000:d::a6])
by psf.upfronthosting.co.za (Postfix) with ESMTPS id 537811C9D8
for ; Sat, 8 Sep 2012 11:26:32 +0200 (CEST)
Received: from albatross.python.org (localhost [127.0.0.1])
by mail.python.org (Postfix) with ESMTP id 3XDVWr0bDqzQ7Z
for ; Sat, 8 Sep 2012 11:26:32 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901;
t=1347096392; bh=6dc5mdv4dzL5yW3ZVn8qW7XJ3IHvTCmeY0s1ykUK9k4=;
h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To:
Subject:Message-Id:Date;
b=D8YO9tFWN0XXGgKQYxrCFD/5gAjlPqoCT/u8iuZcrn6ELcSY0XjT6d61kJRULvCyH
EHauP0hVfuZ0DyFuxmGcqROWZgVbe2kV2G2H7hUnRUgoVPp+YdWOjbLt0qVV+1Deff
nstshu+2MVQFJFr/+lskdt5QvARUw+WEKRFjvCA8=
Received: from localhost (HELO mail.python.org) (127.0.0.1)
by albatross.python.org with SMTP; 08 Sep 2012 11:26:32 +0200
Received: from virt-7yvsjn.psf.osuosl.org (virt-7yvsjn.psf.osuosl.org
[140.211.10.72])
by mail.python.org (Postfix) with ESMTP
for ; Sat, 8 Sep 2012 11:26:31 +0200 (CEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
From: [email protected]
To: [email protected]
Subject: [issue715365]
Message-Id: <[email protected]>
Date: Sat, 8 Sep 2012 11:26:32 +0200 (CEST)
TmV3IGNoYW5nZXNldCBkZjY2MzYwM2U2N2EgYnkgU3RlZmFuIEtyYWggaW4gYnJhbmNoICczLjIn
OgpJc3N1ZSAjMTU4Njg6IEZpeCByZWZsZWFrIGluIGJ5dGVzaW8uYyAoQ292ZXJpdHkgIzcxNTM2
NSkuCmh0dHA6Ly9oZy5weXRob24ub3JnL2NweXRob24vcmV2L2RmNjYzNjAzZTY3YQo=
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/py
Re: [Python-Dev] Coverity scan
Christian Heimes wrote: > IMHO it makes sense to define a workflow how we are going to handle > Coverity issues. Each coverity issue has an identifier and can have > information like an external reference and an action. I've seen that you > have started to create bugs in our tracker. How about we mention the > Coverity # in the bug and add a link to the bug in the "Ext. Reference" > field of the Coverity issue and set the Action to "Claimed, being worked > on". That sounds good in principle. I'm only worried that for casual readers of either the commit messages or the tracker issues the importance of the Coverity tool might be overstated. After all, 99.99% of issues are either found by developers themselves or by gcc, Visual Studio, Valgrind, etc. It just occurred to me that for example we don't credit other tools in commit messages. That said, for users of the Coverity web interface it's clearly useful. Stefan Krah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coverity scan
Zitat von Stefan Krah : After all, 99.99% of issues are either found by developers themselves or by gcc, Visual Studio, Valgrind, etc. It just occurred to me that for example we don't credit other tools in commit messages. I agree that Coverity doesn't need to be mentioned in commit message. We do cite tools occasionally, but in a negative way, such as "silence gcc warning", where the commit message and/or comment explains why some code is ugly for some non-obvious reason. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Failed issue tracker submission
Python tracker wrote:
>
>
> The node specified by the designator in the subject of your message
> ("715365") does not exist.
>
> Subject was: "[issue715365]"
Is this related to the Coverity ID being mentioned in
http://bugs.python.org/issue15868 ?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Failed issue tracker submission
Petri Lehtinen wrote:
> > ("715365") does not exist.
>
> Is this related to the Coverity ID being mentioned in
> http://bugs.python.org/issue15868 ?
Must be. I used the pattern # twice in the commit message:
http://hg.python.org/cpython/rev/df663603e67a
So let's avoid that in the future.
Stefan Krah
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Failed issue tracker submission
On Sat, Sep 8, 2012 at 9:17 PM, Stefan Krah wrote:
> Petri Lehtinen wrote:
>> > ("715365") does not exist.
>>
>> Is this related to the Coverity ID being mentioned in
>> http://bugs.python.org/issue15868 ?
>
> Must be. I used the pattern # twice in the commit message:
>
> http://hg.python.org/cpython/rev/df663603e67a
No, using the pattern number twice is OK now - it's using it for an
issue that *doesn't exist* that broke.
Better to just not use that notation for the Coverity ID's by writing
"CID 715365" or something similar so we don't get any false hits on
the tracker integration.
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): Issue #15591 and Issue #11715: silence output of setup.py when make is run with
On Fri, 7 Sep 2012 02:27:25 +0200 (CEST) christian.heimes wrote: > http://hg.python.org/cpython/rev/8cd6acffbcb9 > changeset: 78871:8cd6acffbcb9 > branch: 2.7 > parent: 78867:2587aeb616b6 > user:Christian Heimes > date:Fri Sep 07 00:55:33 2012 +0200 > summary: > Issue #15591 and Issue #11715: silence output of setup.py when make is run > with -s option. > > files: Looks like you committed an empty changeset, as a result the 2.7 FreeBSD buildbot is still broken: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%202.7 Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coverity scan
On Sat, Sep 8, 2012 at 6:41 AM, wrote: > > Zitat von Stefan Krah : > > After all, 99.99% of issues are either found by developers themselves or >> by gcc, Visual Studio, Valgrind, etc. It just occurred to me that for >> example >> we don't credit other tools in commit messages. >> > > I agree that Coverity doesn't need to be mentioned in commit message. > We do cite tools occasionally, but in a negative way, such as "silence > gcc warning", where the commit message and/or comment explains why some > code is ugly for some non-obvious reason. > Well, when I fix bugs found by Clang's static analyzer (which I ran out time to do for 3.3) I try to remember to thank the tool. IOW I don't think thanking a tool hurts, but in no way is required required either. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coverity scan
Am 08.09.2012 11:35, schrieb Stefan Krah: > That sounds good in principle. I'm only worried that for casual readers > of either the commit messages or the tracker issues the importance of > the Coverity tool might be overstated. > > After all, 99.99% of issues are either found by developers themselves or > by gcc, Visual Studio, Valgrind, etc. It just occurred to me that for example > we don't credit other tools in commit messages. I'd like to avoid that two people create two bug tracker entries or work on the same issue at the same time. The CID (coverity id) also makes it easier to find the entry on the Coverity site. IMHO it's sufficient to mention the CID in the tracker entry. As Brett has said it's also nice to give credits, too. By the way I've automated the build and upload process. Every six hours the default branch is pulled from hg and a build is triggere when changes are detected. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): Issue #15591 and Issue #11715: silence output of setup.py when make is run with
Am 08.09.2012 16:52, schrieb Antoine Pitrou: > On Fri, 7 Sep 2012 02:27:25 +0200 (CEST) > christian.heimes wrote: >> http://hg.python.org/cpython/rev/8cd6acffbcb9 >> changeset: 78871:8cd6acffbcb9 >> branch: 2.7 >> parent: 78867:2587aeb616b6 >> user:Christian Heimes >> date:Fri Sep 07 00:55:33 2012 +0200 >> summary: >> Issue #15591 and Issue #11715: silence output of setup.py when make is run >> with -s option. >> >> files: > > Looks like you committed an empty changeset, as a result the 2.7 > FreeBSD buildbot is still broken: > http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%202.7 Thanks! I took care of the problem. The patch somehow got stuck in my outgoing queue. I'm still a bit uncertain how to handle edge cases. #python-dev is really helpful. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Online docs: make index search available everywhere
On Thu, Sep 6, 2012 at 10:26 AM, R. David Murray wrote: > On Thu, 06 Sep 2012 13:15:14 -0400, Terry Reedy wrote: >> My understanding is that the tracker is for the cpython repository at >> hg.python.org and my impression is that web code is elsewhere. > > That is true. However, the appearance and functionality of the doc web > pages is entirely controlled by Sphinx, and thus by the sources checked > in to the code repository. This raises a related question. Where should we file issues for Python-controlled things that are outside the scope of the cpython repository (or the devguide) and that are not issues with the tracker (which has its own tracker -- the meta tracker). For example, where should we file an issue for hg.python.org if we suspect the issue is with how we've customized things rather than with Mercurial's hgweb itself. The main bugs tracker has a component for "Devguide" but not for other non-cpython repository things like hg.python.org. --Chris ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Online docs: make index search available everywhere
On Sun, Sep 9, 2012 at 6:18 AM, Chris Jerdonek wrote: > This raises a related question. Where should we file issues for > Python-controlled things that are outside the scope of the cpython > repository (or the devguide) and that are not issues with the tracker > (which has its own tracker -- the meta tracker). > > For example, where should we file an issue for hg.python.org if we > suspect the issue is with how we've customized things rather than with > Mercurial's hgweb itself. The main bugs tracker has a component for > "Devguide" but not for other non-cpython repository things like > hg.python.org. As far as I know, we don't have a general ticketing system for python.org infrastructure. That may change at some point in the future, but in the meantime I just email python-committers or python-dev if I notice something that appears broken with the development infrastructure, or pydotorg-www for the website in general. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Online docs: make index search available everywhere
On Sep 8, 2012, at 8:16 PM, Nick Coghlan wrote: > On Sun, Sep 9, 2012 at 6:18 AM, Chris Jerdonek > wrote: >> This raises a related question. Where should we file issues for >> Python-controlled things that are outside the scope of the cpython >> repository (or the devguide) and that are not issues with the tracker >> (which has its own tracker -- the meta tracker). >> >> For example, where should we file an issue for hg.python.org if we >> suspect the issue is with how we've customized things rather than with >> Mercurial's hgweb itself. The main bugs tracker has a component for >> "Devguide" but not for other non-cpython repository things like >> hg.python.org. > > As far as I know, we don't have a general ticketing system for > python.org infrastructure. That may change at some point in the > future, but in the meantime I just email python-committers or > python-dev if I notice something that appears broken with the > development infrastructure, or pydotorg-www for the website in > general. In the absence of a tracker for "other" Python development issues, why not allow such issues to be filed with the main tracker in the meantime? Otherwise, there is no clear way to record or track progress made on those issues. In the meantime, I will post my issue to python-dev. --Chris Sent from my iPhone ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] hg.python.org issue: log page entries don't always link to revision
On hg.python.org, it seems like the entries on the "log" page don't always link to the corresponding revision: http://hg.python.org/cpython/shortlog This seems to happen whenever the revision description begins with text that results in a link to something else (e.g. an issue number), for example: "Issue #15822: Fix installation of lib2to3 grammar pickles to ensure." In contrast, the "graph" page seems always to link to the revision: http://hg.python.org/cpython/graph Related to this, if the description field contains text that results in a link to something else, then the UI doesn't make a distinction between the portion of the description that links to the revision and the portion that links to the something else. For example, with description text "Fix for fcc629208842", "Fix for" links to the revision for the log entry, but "fcc629208842" links to the named revision, and there is no separation or visual indicator that the two portions of text link to different things. It might be better if the revision link was separate from the description text. That would be one way to address both of the issues above. --Chris ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hg.python.org issue: log page entries don't always link to revision
On Sat, Sep 8, 2012 at 10:29 PM, Chris Jerdonek wrote: > On hg.python.org, it seems like the entries on the "log" page don't > always link to the corresponding revision: > > http://hg.python.org/cpython/shortlog > > This seems to happen whenever the revision description begins with > text that results in a link to something else (e.g. an issue number), > for example: > > "Issue #15822: Fix installation of lib2to3 grammar pickles to ensure." Sorry, the above is not an example of the behavior (since the leading word "Issue" does in fact link to the revision). Here is a better example: "#15865: merge with 3.2." --Chris > In contrast, the "graph" page seems always to link to the revision: > > http://hg.python.org/cpython/graph > > Related to this, if the description field contains text that results > in a link to something else, then the UI doesn't make a distinction > between the portion of the description that links to the revision and > the portion that links to the something else. > > For example, with description text "Fix for fcc629208842", "Fix for" > links to the revision for the log entry, but "fcc629208842" links to > the named revision, and there is no separation or visual indicator > that the two portions of text link to different things. > > It might be better if the revision link was separate from the > description text. That would be one way to address both of the issues > above. > > --Chris ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
