[Tracker-discuss] [issue611] Update issue with a commit information

Maciej Szulik added the comment: Berker's date patch applied here: https://hg.python.org/tracker/roundup/rev/5d2e54d9b327 All the others were addressed here: https://hg.python.org/tracker/roundup/rev/68b787ac295b ___ PSF Meta Tracker

[Tracker-discuss] [issue611] Update issue with a commit information

Maciej Szulik added the comment: > Another alternative is to only send notifications for 2.7 and master branches > for now That's reasonable approach. I think we've talked about it with Brett and Ezio some time ago. > perhaps we could store these events in a queue, then periodically group t

[Tracker-discuss] [issue611] Update issue with a commit information

Berker Peksag added the comment: The attached patch should fix the empty date issue. ___ PSF Meta Tracker ___diff --git a/roundup/githu

[Tracker-discuss] [issue611] Update issue with a commit information

Berker Peksag added the comment: Another alternative is to only send notifications for 2.7 and master branches for now [1] For example, see http://bugs.python.org/issue29407 we would only see the latest notification with this approach: http://bugs.python.org/msg286687 Since commit hashes don't

[Tracker-discuss] [issue611] Update issue with a commit information

Zachary Ware added the comment: > Multiple emails due to multiple branches - unfortunately won't, b/c each push > is against separate > branch and when processing that I don't know anything about related pushes. Fair enough; if we can't do it, we can't do it [1]. Fixing the automatic closing

[Tracker-discuss] [issue611] Update issue with a commit information

Maciej Szulik added the comment: > This seems to have some odd behavior, see for example > https://bugs.python.org/issue29381 > Each action (add message, change status, change resolution, change stage) all > happened separately, which means 4 separate emails sent to everyone on the > nosy lis

[Tracker-discuss] [issue611] Update issue with a commit information

Zachary Ware added the comment: Note https://mail.python.org/pipermail/docs/2017-February/thread.html The multiple email issue is definitely going to need to be fixed sooner rather than later :) Also, I just noticed that the date is not set on the messages. ___

[Tracker-discuss] [issue611] Update issue with a commit information

Berker Peksag added the comment: > Also, automatic closure isn't the correct behavior, [...] I agree with Zachary. BTW, there is a separate issue to set appropriate fields when an issue is manually closed: http://psf.upfronthosting.co.za/roundup/meta/issue595 (I should probably apply it :))

[Tracker-discuss] [issue611] Update issue with a commit information

Zachary Ware added the comment: This seems to have some odd behavior, see for example https://bugs.python.org/issue29381 Each action (add message, change status, change resolution, change stage) all happened separately, which means 4 separate emails sent to everyone on the nosy list. Also, a

[Tracker-discuss] [issue611] Update issue with a commit information

Maciej Szulik added the comment: Committed in https://hg.python.org/tracker/roundup/rev/bcf18f92716d. -- status: in-progress -> testing ___ PSF Meta Tracker _

[Tracker-discuss] [issue611] Update issue with a commit information

Maciej Szulik added the comment: Patch with comments from Ezio addressed and additionally supporting closing issues. ___ PSF Meta Tracker

[Tracker-discuss] [issue611] Update issue with a commit information

Ezio Melotti added the comment: > I've changed it to set_roundup_user, not sure what kind of constant you were > talking about. I meant a constant for the python-dev user you find with: user_ids = self.db.user.filter(None, {'username': 'python-dev'}) Since the python-dev user is not going to c

[Tracker-discuss] [issue611] Update issue with a commit information

Maciej Szulik added the comment: Patch updated and most importantly tested with github. Comments inline below: > I think you'll end up with a user_id in the >1 case and a list (assuming > filter returns a list) in the <1 case. At the end you take the first element > of the list, which is > c

[Tracker-discuss] [issue611] Update issue with a commit information

Brett C. added the comment: Ezio seems to be right about user_id and getting a list or a name depending on which branch is taken based on the line that sets user_id initially. It also might be clearer if you check for `not len(user_id)` or `len(user_id) == 0` instead of `len(user_id) < 1`. An

[Tracker-discuss] [issue611] Update issue with a commit information

New submission from Ezio Melotti: I haven't tried the patch yet, but in +if len(user_id) > 1: +# pick first matching user, when multiple found +user_id = user_id[0] +elif len(user_id) < 1: +# set bpobot as userid when none is found +