From metatracker at psf.upfronthosting.co.za  Sat Jan  7 16:39:20 2012
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 07 Jan 2012 15:39:20 +0000
Subject: [Tracker-discuss] [issue415] Mercurial integration: regression in
	diff generation
In-Reply-To: <1312642512.39.0.425778233696.issue415@psf.upfronthosting.co.za>
Message-ID: <1325950760.32.0.389080473338.issue415@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Using the mercurial diff format is intentional - the git format is utterly broken and must not be used.
?utterly broken? is a very strong opinion.  The git diff format supports things that unified diff does not and has one drawback to my knowledge (I forgot exactly what?it was one missing piece of information that you mentioned during one of the python-dev threads about Mercurial migration or Roundup-Mercurial integration).  Everyone recommends always using git diffs.

> As for changes that are reverted: what changes specifically? (or: what versions should it have compared
> instead of comparing 0c1c9bb590a9 and bc362109eed8?)
I?m sorry I don?t know exactly.  I have this comment from the bug report:

> I'm not sure how the bugtracker patch mechanism works, but the patch it produced included a lot of changes > that I didn't make (changesets already committed to the master repo).

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue415>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sat Jan  7 19:11:26 2012
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 07 Jan 2012 18:11:26 +0000
Subject: [Tracker-discuss] [issue415] Mercurial integration: regression in
	diff generation
In-Reply-To: <1325950760.32.0.389080473338.issue415@psf.upfronthosting.co.za>
Message-ID: <4F088ACC.2080908@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> ?utterly broken? is a very strong opinion.  The git diff format
> supports things that unified diff does not and has one drawback to my
> knowledge (I forgot exactly what?it was one missing piece of
> information that you mentioned during one of the python-dev threads
> about Mercurial migration or Roundup-Mercurial integration).
> Everyone recommends always using git diffs.

That's because nobody (except for the Rietveld integration) needs to
apply patches automatically, apparently - else people would have
noticed that the format is just unusable, for this kind of application.

Notice that this holds for Mercurial's implementation of git-style
diffs. The ones generated by git don't have this issue.

> 
>> As for changes that are reverted: what changes specifically? (or:
>> what versions should it have compared instead of comparing
>> 0c1c9bb590a9 and bc362109eed8?)
> I?m sorry I don?t know exactly.  I have this comment from the bug
> report:
> 
>> I'm not sure how the bugtracker patch mechanism works, but the
>> patch it produced included a lot of changes > that I didn't make
>> (changesets already committed to the master repo).

I think that claim is incorrect. Unless it can be demonstrated with
specific chunks that are there but ought not, I propose to close
this issue as invalid.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue415>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sun Jan  8 15:25:32 2012
From: metatracker at psf.upfronthosting.co.za (Antoine Pitrou)
Date: Sun, 08 Jan 2012 14:25:32 +0000
Subject: [Tracker-discuss] [issue264] Mail gateway borks quotes and console
	sessions
In-Reply-To: <1239122891.37.0.849970456048.issue264@psf.upfronthosting.co.za>
Message-ID: <1326032732.23.0.471087171583.issue264@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ping. This is annoying people on a daily basis.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue264>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sat Jan 21 13:42:57 2012
From: metatracker at psf.upfronthosting.co.za (Nick Coghlan)
Date: Sat, 21 Jan 2012 12:42:57 +0000
Subject: [Tracker-discuss] [issue433] Tracker is resolving at the network
	level, but is unusably slow
Message-ID: <1327149777.78.0.873161249297.issue433@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The cynic in me makes me think someone may be encouraging us to fix the hash collision bug by DoS'ing the issue tracker with it...

----------
messages: 2364
nosy: ncoghlan
priority: critical
status: unread
title: Tracker is resolving at the network level, but is unusably slow

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue433>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sat Jan 21 13:50:20 2012
From: metatracker at psf.upfronthosting.co.za (Ezio Melotti)
Date: Sat, 21 Jan 2012 12:50:20 +0000
Subject: [Tracker-discuss] [issue433] Tracker is resolving at the network
	level, but is unusably slow
In-Reply-To: <1327149777.78.0.873161249297.issue433@psf.upfronthosting.co.za>
Message-ID: <1327150220.94.0.710145655354.issue433@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think that's because www.python.org is down, and the tracker loads a few resources from there.  I removed some of these dependencies (mainly CSSs) but there are a couple left (the logo and another CSS IIRC).  I could copy them on bugs.python.org so that it doesn't have to load them from www.pythong.org.

----------
nosy: +ezio.melotti
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue433>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sat Jan 21 14:00:25 2012
From: metatracker at psf.upfronthosting.co.za (Nick Coghlan)
Date: Sat, 21 Jan 2012 13:00:25 +0000
Subject: [Tracker-discuss] [issue415] Mercurial integration: regression in
	diff generation
In-Reply-To: <1312642512.39.0.425778233696.issue415@psf.upfronthosting.co.za>
Message-ID: <1327150825.83.0.365498015801.issue415@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

If you get repeated application of upstream changes in generated patches, it's a sign that the patch generator is having trouble finding the right base version to compare against. Usually this happens due to daisy chaining of merges, so a CPython version gets merged, but never appears directly as an ancestor of the revision that is being merge (instead, the relevant CPython version appears only as an ancestor of the alternate branch of a merge commit).

For example, I used to have this problem all the time when I was running two feature branches in my sandbox repo, where feature B depended on feature A. If I did the merge flow of upstream changes as default->A->B then the diffs generated for the B branch were always useless (they included changes already part of upstream). After much back and forth with Martin, we figured out that this was the problem and changing my merge workflow to be default->A, default->B, and only doing A->B merges when A itself changed, would allow the automatic patch generator to do the right thing.

Another way to get yourself in trouble is to merge directly from hg.python.org into a feature branch, then merge that feature branch into your default branch - again, the patch generator can't see the correct CPython revision in that case (because it is off on the feature branch, not on default).

So nothing's actually changed here, but the constraints on merge practices if you want the patch generator to produce correct patches could use a solid explanation somewhere in the devguide.

----------
nosy: +ncoghlan

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue415>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sat Jan 21 14:06:19 2012
From: metatracker at psf.upfronthosting.co.za (Nick Coghlan)
Date: Sat, 21 Jan 2012 13:06:19 +0000
Subject: [Tracker-discuss] [issue433] Tracker is resolving at the network
	level, but is unusably slow
In-Reply-To: <1327149777.78.0.873161249297.issue433@psf.upfronthosting.co.za>
Message-ID: <1327151179.69.0.510495728672.issue433@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yes please - one of the big reasons we switched off SF to our own tracker was to improve tracker reliability (SourceForge stability at the time was terrible - they've improved things a lot since then). Upfront's offer of fully supported hosting was a big part of choosing RoundUp over Atlassian's offer of a JIRA instance.

Currently, the dependency on www.python.org assets means that the bug tracker is inheriting any flakiness in the main site, so we're not really taking advantage of the extra stability Upfront can provide.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue433>
_______________________________________________________

From martin at v.loewis.de  Sat Jan 21 14:50:35 2012
From: martin at v.loewis.de (martin at v.loewis.de)
Date: Sat, 21 Jan 2012 14:50:35 +0100
Subject: [Tracker-discuss] [issue415] Mercurial integration: regression
 in diff generation
In-Reply-To: <1327150825.83.0.365498015801.issue415@psf.upfronthosting.co.za>
References: <1327150825.83.0.365498015801.issue415@psf.upfronthosting.co.za>
Message-ID: <20120121145035.Horde.eHSeQ8L8999PGsKri9pwhCA@webmail.df.eu>

> If you get repeated application of upstream changes in generated  
> patches, it's a sign that the patch generator is having trouble  
> finding the right base version to compare against. Usually this  
> happens due to daisy chaining of merges, so a CPython version gets  
> merged, but never appears directly as an ancestor of the revision  
> that is being merge (instead, the relevant CPython version appears  
> only as an ancestor of the alternate branch of a merge commit).

I still don't believe that this is the case. Please provide some
actual proof of such claims, by means of a specific repository,
a specific patch created out of it, and a specific revision id
of a change that should or should not have been included in the patch.

> For example, I used to have this problem all the time when I was  
> running two feature branches in my sandbox repo, where feature B  
> depended on feature A. If I did the merge flow of upstream changes  
> as default->A->B then the diffs generated for the B branch were  
> always useless (they included changes already part of upstream).  
> After much back and forth with Martin

It seems we have to do more back and forth. If some revision of default
is ancestor of B's head (by merge through A), that revision cannot
possibly appear in the patch: the patch generator finds the newest
revision of default that is ancestor of B.

You may be misremembering: the patch *will* include changes of A that
have not been merged into default. It *will not* include changes of
upstream that have already been merged.

> So nothing's actually changed here, but the constraints on merge  
> practices if you want the patch generator to produce correct patches  
> could use a solid explanation somewhere in the devguide.

Apparently, I'm incapable of describing how this patch generation works
in a way that people really understand. So somebody else will have
to provide the text.


From metatracker at psf.upfronthosting.co.za  Sat Jan 21 14:52:01 2012
From: metatracker at psf.upfronthosting.co.za (Ezio Melotti)
Date: Sat, 21 Jan 2012 13:52:01 +0000
Subject: [Tracker-discuss] [issue433] Tracker is resolving at the network
	level, but is unusably slow
In-Reply-To: <1327149777.78.0.873161249297.issue433@psf.upfronthosting.co.za>
Message-ID: <1327153921.89.0.0338250313757.issue433@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Should be fixed in r88933.  The CSS included a few background-images, so I had to copy them too and tweak the links.
This is the list of files:
Adding  (bin)  html/bullet.gif
Adding  (bin)  html/button-on-bg.png
Adding  (bin)  html/header-bg2.png
Adding         html/main.css
Adding  (bin)  html/nav-off-bg.png
Adding  (bin)  html/nav-on-bg.png
Sending        html/page.html
Adding  (bin)  html/python-logo.gif

----------
assignedto:  -> ezio.melotti
status: chatting -> resolved

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue433>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Mon Jan 23 21:23:06 2012
From: metatracker at psf.upfronthosting.co.za (Retro)
Date: Mon, 23 Jan 2012 20:23:06 +0000
Subject: [Tracker-discuss] [issue434] ProgrammingError revealing server info
Message-ID: <1327350186.37.0.213968267021.issue434@psf.upfronthosting.co.za>


New submission from Retro <mamatijekurba at gmail.com>:

I wanted to delete a patch set that I have uploaded to a Python issue reporting portal @ http://bugs.python.org, but I got a

"ProgrammingError at /review/13816/patchset/4039/delete
schema "datetime" does not exist"

and got all the Django nitty-gritty info about the Python server. This is not good because someone can misuse that information. Please fix this. The "DEBUG = True" is set and so all the details about the Python server is out on the open. Better change that to "DEBUG = False" and let the user get a standard 500 error page instead.

It says at the bottom: "You're seeing this error because you have DEBUG = True in your Django settings file. Change that to False, and Django will display a standard 500 page."

And, of course, fix the ProgrammingError so that the option "Delete Patch Set" would work. :)

----------
messages: 2369
nosy: Retro
priority: critical
status: unread
title: ProgrammingError revealing server info

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue434>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Mon Jan 23 22:09:31 2012
From: metatracker at psf.upfronthosting.co.za (Ezio Melotti)
Date: Mon, 23 Jan 2012 21:09:31 +0000
Subject: [Tracker-discuss] [issue434] ProgrammingError while deleting patch
	set
In-Reply-To: <1327350186.37.0.213968267021.issue434@psf.upfronthosting.co.za>
Message-ID: <1327352971.22.0.967638113468.issue434@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I now set DEBUG = False in gae2django/settings.py and rietveld/settings.py.

----------
nosy: +ezio.melotti, loewis
priority: critical -> bug
status: unread -> chatting
title: ProgrammingError revealing server info -> ProgrammingError while deleting patch set

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue434>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Mon Jan 23 22:56:45 2012
From: metatracker at psf.upfronthosting.co.za (Retro)
Date: Mon, 23 Jan 2012 21:56:45 +0000
Subject: [Tracker-discuss] [issue434] ProgrammingError while deleting patch
	set
In-Reply-To: <1327350186.37.0.213968267021.issue434@psf.upfronthosting.co.za>
Message-ID: <1327355805.67.0.626351975917.issue434@psf.upfronthosting.co.za>


Retro <mamatijekurba at gmail.com> added the comment:

Good. But don't forget to fix the bug as well.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue434>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Thu Jan 26 10:03:13 2012
From: metatracker at psf.upfronthosting.co.za (Retro)
Date: Thu, 26 Jan 2012 09:03:13 +0000
Subject: [Tracker-discuss] [issue435] Rietveld Code Review Tool bugs
Message-ID: <1327568593.26.0.104803212189.issue435@psf.upfronthosting.co.za>


New submission from Retro <mamatijekurba at gmail.com>:

The Rietveheld Code Review Tool has 3 bugs:

1) Rietveld Code Review Tool isn't able to delete a patch set. For the patches that I create it displays a "Delete patch set" option, but it is broken. Always displays the 500 error page. I am not able to delete *any* of my patches that I want.

2) The option "Download raw patch set" is not broken, however, but has a sementic error. It does not download anything, it just *displays* the patch in the browser, not offers to save a *.diff or *.patch file.

3) When the "Delete patch set" option is present besides the "Download raw patch set", the former is squeezed to the delimiting symbol (the | symbol). It looks like this:
"Download raw patch set |Delete patch set"
which should have been displayed as
"Download raw patch set | Delete patch set"

----------
messages: 2372
nosy: Retro
priority: bug
status: unread
title: Rietveld Code Review Tool bugs

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue435>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Fri Jan 27 19:05:02 2012
From: metatracker at psf.upfronthosting.co.za (Ezio Melotti)
Date: Fri, 27 Jan 2012 18:05:02 +0000
Subject: [Tracker-discuss] [issue435] Rietveld Code Review Tool bugs
In-Reply-To: <1327568593.26.0.104803212189.issue435@psf.upfronthosting.co.za>
Message-ID: <1327687502.79.0.183740616357.issue435@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

1) This is handled in issue434.
2) I don't think that's a problem, it allows me to see a plain diff and I can always wget the url.
3) Looks fine here, can you provide more information (e.g. browser used, viewport size, exact location of the text)?

----------
nosy: +ezio.melotti
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue435>
_______________________________________________________