If there is objection I will happily revert it, but I needed to mark an
issue on bugs.python.org as still needing backport, since I'd merged
the fix and the PR is now closed but I have no time currently to learn
about how to do backports(*). So I added a 'backport needed' status
to the tracker.
I
On Thu, 11 Aug 2016 22:09:33 +0200, Maciej Szulik wrote:
> On Tue, Aug 2, 2016 at 4:24 PM, R. David Murray
> wrote:
>
> > On Sat, 30 Jul 2016 23:21:07 +0200, Maciej Szulik
> > wrote:
> > > I'm leaning towards just adding an information who left the comment
On Sat, 30 Jul 2016 23:21:07 +0200, Maciej Szulik wrote:
> I'm leaning towards just adding an information who left the comment
> and a link to the PR. I agree with Senthil that gh comments,
> especially those coming from reviews have code context, which will get
> lost when copying over. Besides t
On Wed, 27 Jul 2016 16:08:52 -0700, Senthil Kumaran wrote:
> On Wed, Jul 27, 2016 at 2:57 PM, R. David Murray
> wrote:
> > The general consensus (a while back) was that the fact that reitveld
> > doesn't update the bug tracker issue is a bug, and we're trying
On Wed, 27 Jul 2016 16:08:52 -0700, Senthil Kumaran wrote:
> On Wed, Jul 27, 2016 at 2:57 PM, R. David Murray
> wrote:
> > The general consensus (a while back) was that the fact that reitveld
> > doesn't update the bug tracker issue is a bug, and we're trying
On Wed, 27 Jul 2016 14:00:09 -0700, Senthil Kumaran wrote:
> On Wed, Jul 27, 2016 at 1:00 PM, Anish Shah wrote:
> > it checks if any "GitHub" comment was added in last "X" minutes. If no
> > GitHub comments were added, then it adds that comment to the linked issue.
>
> I guess, you meant, "if a
On Tue, 05 Jan 2016 17:50:53 +, Brett Cannon wrote:
> If people are that worried, we could do a daily dump of the data. But
> unless we can have all GitHub-related comments to an issue not trigger an
> email update I don't think that's feasible as it would mean two emails for
> every PR commen
On Fri, 01 Jan 2016 20:25:11 +, Stefan Krah
wrote:
> Brett Cannon writes:
> > I don't think this will be a shock to anyone who has followed the
> discussion on this list. The decision is essentially based on:
>
> We must have been reading different discussions: On *this* list more
> people
On Mon, 14 Dec 2015 16:03:57 -0500, Barry Warsaw wrote:
> On Dec 14, 2015, at 08:48 PM, Brett Cannon wrote:
>
> >What that comment would do is trigger a bot
>
> As long as we a clear, responsive owner of the bot, and a plan for when it
> inevitably dies or does the wrong thing. If the bot is go
On Sat, 12 Dec 2015 10:07:14 -0800, Guido van Rossum wrote:
> One more repost from gu...@python.org. Why is this list so picky?
I added your gmail address to the accept filter. I presume that means
it will now allow you to post from there in the future.
--David
_
On Wed, 02 Dec 2015 14:23:41 -0500, Donald Stufft wrote:
>
> > On Dec 2, 2015, at 2:21 PM, R. David Murray wrote:
> >
> > That's interesting. I thought someone had already tried travis and our
> > test suite took too long to run. Sounds like Kushal's s
On Wed, 02 Dec 2015 18:58:34 +, Brett Cannon wrote:
> On Wed, 2 Dec 2015 at 10:50 R. David Murray wrote:
>
> > On Wed, 02 Dec 2015 18:34:49 +, Brett Cannon wrote:
> > > And this bot doesn't have to do it, but we should definitely make sure we
> > >
On Wed, 02 Dec 2015 18:34:49 +, Brett Cannon wrote:
> And this bot doesn't have to do it, but we should definitely make sure we
> have at least automated testing of all PRs on *some* OS and also a way to
Kushal did some work in this direction (for unix builds), but we haven't
done anything wi
On Tue, 11 Aug 2015 07:12:38 +0300, Ezio Melotti wrote:
> On Sun, Aug 9, 2015 at 12:25 AM, Brett Cannon wrote:
> >
> >
> > On Sat, Aug 8, 2015 at 1:18 PM R. David Murray
> > wrote:
> >>
> >> On Sat, 08 Aug 2015 17:44:04 -, Brett Cannon
> &g
On Sat, 08 Aug 2015 17:44:04 -, Brett Cannon wrote:
> OK, assuming David's in agreement then I think this approach wins with the
> comma-separated field for commits that the hg hook for Roundup auto-appends
> to and of course the field to enter the NEWS entry.
>
> Now the next question is how
On Thu, 06 Aug 2015 18:16:53 -, Brett Cannon wrote:
> > However, having a commit log based generator offers a relatively
> > decent way to deal with that: a Misc/NEWS.overrides directory, with
> > filename prefixes based on the commit hashes to be overridden.
> >
>
> This is making me prefer
On Wed, 05 Aug 2015 17:59:32 -, Brett Cannon wrote:
> I already assumed we were going to tweak how we did Misc/NEWS somehow,
> whether it was separate files for each release/branch, somehow
> automatically generating it from commits, etc. If David's up for hashing it
> out with me I'm sure we
On Mon, 20 Jul 2015 19:49:50 -, Brett Cannon wrote:
> In my ideal workflow scenario, these are the steps a patch would take:
>
>1. Issue is created
>2. Issue is triaged to have right affected versions, etc.
>3. Patch is uploaded
>4. CI kicks the patch off for *all* branches an
On Sat, 21 Mar 2015 23:13:13 +1000, Nick Coghlan wrote:
> I don't think we've discussed it anywhere yet (unless I mentioned it
> to Ezio on IRC), but there are some issues around dependency display
> that could conceivably be handled downstream. The main one is showing
> which bugs a given bug is
On Mon, 16 Mar 2015 22:07:16 +0530, Saimadhav Heblikar
wrote:
> I am currently looking at the design of Roundup[1]. Would a standalone
> project as mentioned above be bugs.python.org roundup specific or
> would it target upstream? Which would serve *us* better?
Most of what we have been talking
On Thu, 19 Feb 2015 16:40:45 +0100, Antoine Pitrou wrote:
> You may also ask him to choose a simple username (such as "slavek") to
> make it easy to type without any autofill. I think you can change
> usernames on Roundup.
You can, yes. The real 'user' is a integer identifier, which gets
mapped
Giving him developer privs will allow him to appear in the "assigned to"
list. It has no effect on the tab completion of the nosy field. (Since
any tracker id can appear in the nosy field, I presume it is the tab
completion you are talking about.) Tab completion is controlled by the
experts file
On Wed, 07 May 2014 08:09:03 -0700, Carol Willing
wrote:
> I'm wondering if "decision needed" might be more accurately named
> "triage needed"?
>
> Looking at David's well documented proposals and other mail comments,
> "triage needed" more specifically describes the 'state'.
>
> A few though
I'm a week later than I expected, but I've added my notes to the
discussion summary started by Ezio at:
https://wiki.python.org/moin/TrackerDevelopmentPlanning
Based on the feedback, I propose two major changes compared to my
initial proposal.
The first is to combine 'keywords' and 'componen
On Thu, 24 Apr 2014 23:06:41 +0200, francis wrote:
> >
> >> BTW. from a Non-Dev point of view:
> >>
> >> I just would like to be able to know how far or ready is a patch for
> >> manually review and then commit.
> >
> > Yes, that's part of the goal of my making the state of an issue
> > more fine
On Thu, 24 Apr 2014 14:16:48 +0200, francis wrote:
> > The Django project uses a development dashboard to display numbers
> > like "release blockers", "patches needing review", etc:
> > https://dashboard.djangoproject.com/ It would be good if there is a
> > dashboard like that for CPython (by usin
On Wed, 23 Apr 2014 15:53:39 +0300, Ezio Melotti wrote:
> On Wed, Apr 23, 2014 at 5:17 AM, Nick Coghlan wrote:
> > On 22 April 2014 19:51, Antoine Pitrou wrote:
> >> (it's the same reason I'm rather ambiguous on the whole idea of
> >> sprints)
> >
> > For me, sprints are mostly useful from the p
27 matches
Mail list logo
