On Tue, Mar 2, 2010 at 15:17, Barry Warsaw wrote:
> We really need to move to a dvcs for development sooner rather than later.
> It's been a year since the decision was made. I understand that it will suck
> for Windows developers in the short term, but with all the discussion about
> the PSF pay
On Tue, Mar 2, 2010 at 17:12, Steve Holden wrote:
> And does it look like a non-issue because you are familiar with the
> Windows environment or because your imagination can't conceive of why it
> would be a real problem? Does going ahead make development more
> difficult for the Windows platform?
On Tue, Mar 2, 2010 at 17:52, Michael Foord wrote:
> What is the risk of going ahead with a broken system?
>
> The crux of the matter is that building Python for Windows could break if
> someone accidentally commits the wrong line-endings for a few specific files
> (Visual Studio project and confi
On Tue, Mar 2, 2010 at 18:01, Dirkjan Ochtman wrote:
>> The risk *seems* reasonably low, people on non-Windows platforms are
>> unlikely to touch those files and they are unlikely to be edited by hand,
>> and if the cost of fixing the problem is low it seems reasonable to
On Tue, Mar 2, 2010 at 20:36, Brett Cannon wrote:
> Dirkjan would know where the patch is.
It's in hg.python.org/pymigr (and was previously announced in my
status report on python-dev, I think that was on Feb 10).
Cheers,
Dirkjan
___
python-committers
On Tue, Mar 2, 2010 at 22:51, "Martin v. Löwis" wrote:
> IIUC, it's not just the EOL issue. There are tons of other things to be
> done, and nobody willing to do them - everybody just wants them to be done.
I wouldn't say there are tons of things, but yes, even if we decided
to punt on the whole
On Wed, Mar 3, 2010 at 14:03, Eric Smith wrote:
> Thanks, that's helpful.
>
> But that's manually maintained, right? I was hoping to get something
> generated from the svn configuration.
>
> Unfortunately python-committers doesn't have real names for everyone, so
> it's impossible to match up deve
On Wed, Mar 10, 2010 at 03:13, Jesus Cea wrote:
> This is a really excellent suggestion, and the perfect excuse to get
> familiar with MQ, that I haven't tried yet.
>
> I have a strange error:
>
> """
> [j...@babylon5 home]$ hg clone http://hg.python.org/cpython/
> destination directory: cpython
>
On Sat, Mar 13, 2010 at 00:11, Jesus Cea wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/10/2010 04:30 PM, Jesus Cea wrote:
>> On 03/10/2010 08:29 AM, Dirkjan Ochtman wrote:
>>> So, in the meantime, if you have ssh access, make your clone via ssh.
&
On Sun, Mar 14, 2010 at 00:40, Georg Brandl wrote:
> Thinking of that a bit more: after the Hg transition, shouldn't we be able to
> really freeze a branch that is in pre-release approval-needed mode? It is
> trivial for anyone to commit a fix to their own branch, and then instead of
> pushing th
On Mon, Apr 12, 2010 at 09:35, Tarek Ziadé wrote:
> Since the 2.x line is now feature frozen (since 2.7 is the last 2.x
> release and we have reached beta), most new developments will start in
> the py3k branch.
> I was wondering if it wouldn't make sense to rename the current trunk
> to /py26 and
On Tue, Jun 29, 2010 at 15:12, Barry Warsaw wrote:
> I really think we need to make the switch to Mercurial as soon as 2.7 final is
> out. It's been long enough.
I got back into working on it last week (using a branch map to clean
up all the feature branches we're going to shed for the conversio
On Fri, Jul 2, 2010 at 11:02, Georg Brandl wrote:
> While that would be logical if we continued to use SVN, it's probably not
> worth it when we switch to Hg anyway a short time later, so avoiding the
> potential confusion is better.
Agreed, renaming the branch has the potential of making the con
On Sun, Aug 1, 2010 at 15:49, Jesus Cea wrote:
> How is migration to Mercurial going?. Showstoppers?.
I've been gone for a week and am just now catching up, but a lot of
progress has been made on hgsubversion fixes. I have a problem on the
box where I run the conversion though, and I'm trying to
2010/11/8 Łukasz Langa :
> I see you're basically saying "We're all adults here" and that we should be
> able to control our own environment so these kinds of commits don't happen
> (like Guido said). Well guess what, I believe that isn't going to work. Let
> me tell you why.
I must say I kind of
2010/11/8 Michael Foord :
> You mean `make patchcheck` isn't *already* part of your workflow?
Seems easier to me if I don't have to issue a separate command for it...
Cheers,
Dirkjan
___
python-committers mailing list
[email protected]
http:
All ssh repos can now be accessed by using ssh://[email protected]/repo
instead of ssh://[email protected]/repos/repo. While the old way should
continue to work, the new address should be considered preferable.
Cheers,
Dirkjan
___
python-committers ma
On Wed, Nov 24, 2010 at 15:57, Eric Smith wrote:
> I'd suggest deleting the /repos/ URIs eventually (as in before the end of
> the year). I don't see the need to keep them around and have the maintenance
> burden.
Maybe, but it's currently like three lines in a script, not as if
there's a huge ma
On Sat, Dec 4, 2010 at 16:25, Georg Brandl wrote:
> As sad as it is, that's true. It's just unfair to developers and
> infrastructure providers to switch on such a short notice without a
> testing period.
Yeah, I'm very sorry. The last step in the conversion has proven
pretty annoying to get rig
On Sun, Dec 5, 2010 at 14:58, Jeroen Ruigrok van der Werven
wrote:
> I just wondered why, in light of my having missed the "in addition to", we
> would need to move to xz only, given that disk space is relatively cheap as
> opposed to the real code, et cetera.
Because bandwidth is much more expen
On Fri, Feb 4, 2011 at 14:31, Tarek Ziadé wrote:
> That's why I think it's much cleaner to work with mq to build a clean
> single-commit patch, even if a clone may be used for temporary states
> and sharing.
>
> We are experiencing merge hell right now in Distutils2, as the
> contributor list gro
On Fri, Feb 4, 2011 at 16:49, Nick Coghlan wrote:
> On the other hand, if *any* forward port naturally picks up all the
> missed forward ports, then the Mercurial perspective starts to make
> more sense (especially if the merge is able to exploit the DAG in
> order to make fewer mistakes).
That's
On Fri, Feb 4, 2011 at 17:31, Antoine Pitrou wrote:
>> That's exactly the idea of the Mercurial way. You type hg merge
>> and it will merge everything from the other branch that
>> hasn't been merged yet (where both "blocking", in svnmerge
>> terminology, and merging count as having been merged).
On Fri, Feb 4, 2011 at 17:36, Barry Warsaw wrote:
> Doesn't that mean that the person doing the forward port will potentially have
> to review a lot more code than the fix they specifically want to make?
Potentially, yes. I would imagine in many cases (let's not count 2.x
-> 3.x for now) the merg
On Fri, Feb 4, 2011 at 17:51, Barry Warsaw wrote:
> Sure. I guess my question is, what do *you* do in that case? Are you blocked
> because I didn't do my job properly? Can you tell your merge to ignore my
> change so you can keep making progress, complete your patch, and send me a
> nastygram t
On Sun, Mar 6, 2011 at 11:23, Georg Brandl wrote:
>> If I use hg commit --user, is it possible to see somewhere that the
>> commiter was me?
>
> Basically, no. If you want to honor contributors, put their name into
> the commit message.
You can still see who pushed it in the python-checkins emai
On Wed, Apr 6, 2011 at 16:08, Antoine Pitrou wrote:
> I think the representation of merges as a diff against one of the
> parents is indeed sub-optimal. OTOH, it's not easy to come up with
> something better.
This might be of interest: https://bitbucket.org/wolever/hg-mergediff/.
Cheers,
Dirkja
On Mon, Jul 4, 2011 at 21:01, Antoine Pitrou wrote:
> I've upgraded the Mercurial version on hg.python.org to 1.9.
> Also, I've enabled the experimental "generaldelta" repository feature on
> the server, which makes the repository smaller (down from ~350 MB to
> ~190 MB), regardless of the client
On Wed, Nov 7, 2012 at 2:54 PM, Brett Cannon wrote:
>> If that fails, banning him would show that we care about the quality of
>> communication and technical prowess is no excuse for abusive behavior.
>
> The problem is how do we do that? Do the owners of various systems take it
> upon themselves
On Wed, Nov 7, 2012 at 6:01 PM, Guido van Rossum wrote:
> imagine it must be pretty lonely being the only geek with deep Python
> knowledge and interest in Minsk.
I don't want to distract from your point, but I'm not sure the
underlying assumption is warranted here. I happen to have met a few
pre
On Wed, Nov 7, 2012 at 3:08 PM, R. David Murray wrote:
> If losing him was the only consequence this would be pretty much a
> no-brainer. However, it is likely the consequences of a general ban
> would be more widespread than that (negative publicity, etc).
Not sure I agree with that. As a parti
On Tue, May 28, 2013 at 4:11 PM, Senthil Kumaran wrote:
> While trying to clone a cpython repo to a new repo. I am getting this error.
>
> getting Lib/idlelib/idle.bat
> getting Lib/idlelib/idle.py
> getting Lib/idlelib/idle.pyw
> getting Lib/idlelib/idle_test/@README.txt
> abort: data/Lib/idlelib
On Thu, Jul 18, 2013 at 1:55 AM, Christian Heimes wrote:
> CPython core development heavily relies on automatic tests. We are
> using buildbot for continuous integration since at least 2006. About
> 40 buildbot instances to run 10k test cases on different of platforms
> and architectures: Linux (m
On Sat, Jan 25, 2014 at 2:49 PM, Eli Bendersky wrote:
> Interesting. Chromium has something kind-of similar, named "commit queue",
> for developers without actual commit access. Once they get an LGTM, the
> thing rolls automatically. In fact, core developers often find it useful too
> because the
On Tue, May 12, 2015 at 4:36 PM, Larry Hastings wrote:
> BTW, this workload was exacerbated by my foolish desire to keep the revision
> DAG nice and clean. So I was actually starting over from scratch and
> redoing all the cherry-picking every couple of days, just so I could get all
> the cherry-
35 matches
Mail list logo
