On Fri, Aug 21, 2009 at 16:10, Dj Gilcrease wrote:
> I like this, though maybe .hgextensions since it would contain
> versioned rules and the actual required extension. The extra sub
> directories are not really required IMHO, you just have a hgrc file
> that works the same as the local hgrc file e
On Sat, Aug 22, 2009 at 01:17, Martin Geisler wrote:
> In the general case, you can specify an extension to be enabled by
> filename:
>
> [extensions]
> foo = ~/src/foo
>
> So if I can enable an extension like that on your system, I might be
> evil and commit a bad extension *and* enable it at th
On 05/09/2009 17:09, Antoine Pitrou wrote:
Mercurial is used by e.g. Mozilla, which is not really known for poor Windows
support (chances are many Firefox developers are Windows-based). I wonder
whether they have written their own extension, or if they simply rely on their
text editors to do the
On 05/09/2009 16:59, Stephen J. Turnbull wrote:
git has a nice filter-branch command, which would allow you to
automatically repair the problem (it works basically by checking out
each changeset and rerecording it with the appropriate commands). I
know bzr is growing something similar, so presum
On Sat, Sep 5, 2009 at 18:18, "Martin v. Löwis" wrote:
> But it shouldn't happen often that the server refuses a push;
> all errors should already be caught on the clients.
We could just mandate the same hook code as a commit hook.
Cheers,
Dirkjan
___
On 05/09/2009 18:28, "Martin v. Löwis" wrote:
I would be in favor (although, IIUC, "mandate" here would be a
social thing, not a technical one).
Right, but that would be the same for the extension.
Cheers,
Dirkjan
___
Python-Dev mailing list
Python-
On Sat, Sep 5, 2009 at 18:25, "Martin v. Löwis" wrote:
> I think that's the case. It's pretty much a Unix-only tool, like most of
> the other DVCS implementations.
I know a lot of projects use Mercurial on Windows as well, I'm not
aware of any big problems with it.
> FWIW, I tried to check out Mo
On Tue, Sep 22, 2009 at 15:55, Michael Foord wrote:
> ConfigParser recognises both, but other tools (*coff* ConfigObj) only
> recognises the latter (=).
So does Mercurial, BTW, because this aspect of ConfigParser was pretty
annoying for some of the stuff we try to do (and not at all obvious to
mo
On Thu, Nov 5, 2009 at 23:05, Guido van Rossum wrote:
> I haven't seen substantial opposition against the PEP -- in fact I
> can't recall any, and many people have explicitly posted in support of
> it. So unless opposition suddenly appears in the next few days, I'll
> move it to the Accepted state
On Fri, Nov 6, 2009 at 10:35, Nick Coghlan wrote:
> Longer term, a solution may be to extend the standard deprecation period
> one release and make pending deprecation warnings required rather than
> optional. That way, on the ball developers would have a full release to
> quash deprecation warnin
On Sun, Jan 10, 2010 at 21:25, Brett Cannon wrote:
> Michael has given me the hg transition/stdlib time slot at the language
> summit this year. In regards to that I plan to lead a discussion on:
> * where we are at w/ the Hg transition (Dirkjan should be there and I did a
> blog post on this topi
On Sat, Jan 9, 2010 at 18:29, Benjamin Peterson wrote:
> Please consider trying Python 2.7 with your code and reporting any bugs you
> may
I ran the Mercurial test suite on current trunk, and it worked
alright. There was a small issue with the fact that mimetypes got
fooled by the lack of Import
On Thu, Jan 21, 2010 at 02:56, Collin Winter wrote:
> Agreed. We are actively working to improve the startup time penalty.
> We're interested in getting guidance from the CPython community as to
> what kind of a startup slow down would be sufficient in exchange for
> greater runtime performance.
On Wed, Jan 13, 2010 at 19:51, Guido van Rossum wrote:
> Please mail me topics you'd like to hear me talk about in my keynote
> at PyCon this year.
Your thoughts on "lean stdlib" (obviously not too lean) vs. "fat
stdlib" might be interesting.
Cheers,
Dirkjan
On Thu, Jan 21, 2010 at 18:32, Collin Winter wrote:
> I added startup benchmarks for Mercurial and Bazaar yesterday
> (http://code.google.com/p/unladen-swallow/source/detail?r=1019) so we
> can use them as more macro-ish benchmarks, rather than merely starting
> the CPython binary over and over ag
Hey Collin,
Thanks for the good answers so far!
On Thu, Jan 21, 2010 at 21:14, Collin Winter wrote:
> We used to run the Mercurial correctness tests at every revision, but
> they were incredibly slow and a bit flaky under CPython 2.6. Bazaar's
> tests were faster, but were flakier, so we ended u
On Tue, Feb 2, 2010 at 23:54, Collin Winter wrote:
> Done. The diff is at
> http://codereview.appspot.com/186247/diff2/5014:8003/7002. I listed
> Cython, Shedskin and a bunch of other alternatives to pure CPython.
> Some of that information is based on conversations I've had with the
> respective
It's been a long time!
So for the past few weeks, Mercurial crew member Patrick Mezard has
been hunting for the ugly bug in hgsubversion that I'd previously been
looking at, and it finally got fixed. A new bug popped up, but then we
managed to fix that, too (thanks to the PSF for partially funding
On Sun, Feb 7, 2010 at 22:51, Benjamin Peterson wrote:
> How about a week after, so we have more time to adjust release procedures?
Sounds fine to me.
> Will you do test conversions of the sandbox projects, too?
Got any particular projects in mind?
> Also I think we should have some document (
On Sun, Feb 7, 2010 at 22:58, Mark Hammond wrote:
> Isn't setting a date premature while outstanding issues remain without a
> timetable for their resolution?
If we set a date, that would imply a timetable for their resolution.
> See http://mercurial.selenic.com/wiki/EOLTranslationPlan#TODO - of
On Tue, Feb 9, 2010 at 04:47, Benjamin Peterson wrote:
> I don't believe so. My plan was to manually sync updates or use subrepos.
Using subrepos should work well for this.
It turned out that my local copy of the Subversion repository
contained the Python dir only, so I'm now syncing a full copy
On Wed, Feb 10, 2010 at 02:03, Benjamin Peterson wrote:
> What do you mean by moved? I don't it has ever moved around in the sandbox.
IIRC it was moved into the sandbox from some other location at some point?
Cheers,
Dirkjan
___
Python-Dev mailing lis
On Wed, Feb 10, 2010 at 13:59, Benjamin Peterson wrote:
> The only moving was moving a lot of the files into a lib2to3
> directory. It would be nice if the hg history could be preserved for
> those files.
Please see if hg.python.org/2to3 would satisfy your needs.
Cheers,
Dirkjan
___
On Fri, Feb 12, 2010 at 09:39, Georg Brandl wrote:
> No, it does not. This is also a concern for the Python 2 -> Python 3 merging,
> where (I think) we decided not to have shared history. Transplant already
I don't think this is similar to 2 vs. 3, because 2 vs. 3 are full
branching (so you cou
On Sat, Feb 13, 2010 at 17:14, Barry Warsaw wrote:
> Does hg support an equivalent of 'bzr split'?
>
> % bzr split --help
> Purpose: Split a subdirectory of a tree into a separate tree.
> Usage: bzr split TREE
>
> Options:
> --usage Show usage message and options.
> -v, --verbose Displ
On Sat, Feb 13, 2010 at 12:53, "Martin v. Löwis" wrote:
> Dirkjan: if you agree to such a strategy, please mention that in the PEP.
Having a pushlog and/or including the pusher in the email sounds like
a good idea, I'll add something to that effect to the PEP. I slightly
prefer adding it to the c
On Tue, Feb 16, 2010 at 13:05, wrote:
> Maybe an alternate sprint idea would be to incorporate dateutil into the
> Python core: http://labix.org/python-dateutil
>
> Whoops... (just waking up - still need that first cup of coffee)
>
> While incorporating dateutil into the core would be nice
On Tue, Feb 16, 2010 at 16:26, Tres Seaver wrote:
> Because timezones are defined politically, they change frequently. pytz
> is released frequently (multiple times per year) to accomodate those
> changes: I can't see any way to preserve that flexibility if the
> package were part of stdlib.
By
Hi Collin (and others),
On Sun, Feb 21, 2010 at 15:28, Collin Winter wrote:
> Would it be possible for us to get a Mercurial repository on
> python.org for the Unladen Swallow benchmarks? Maciej and I would like
> to move the benchmark suite out of Unladen Swallow and into
> python.org, where all
On Sun, Feb 21, 2010 at 21:31, Maciej Fijalkowski wrote:
> We probably also need some people, besides CPython devs having some
> access to it (like me).
Right. I've setup a public repository on hg.python.org:
http://hg.python.org/benchmarks/
Right now, I still need to have Martin change some co
On Sun, Feb 21, 2010 at 21:44, Tarek Ziadé wrote:
> We are going to start working on a few things in Distutils at Pycon
> outside the trunk.
This would be full branch of Python? In that case, we probably don't
want to go there yet, because the hashes of the python repository
currently on hg.p.o w
On Sun, Feb 21, 2010 at 22:21, Benjamin Peterson wrote:
> I think we should probably develop a policy about hg.python.org repos
> before we start handing them out. Who will be able to have a repo on
> hg.python.org? What kinds of projects?
I'd be happy to host stuff for people who are already Pyt
On Sun, Feb 21, 2010 at 21:56, Tarek Ziadé wrote:
> No that would be just a new fresh empty repository for "distutils 2"
> that will be developed outside the Python stdlib for a while, and will
> enventually get back into it when it's ready I guess.
>
> I figured it would be easier for people to f
On Sun, Feb 21, 2010 at 23:15, Tarek Ziadé wrote:
> Sounds good, thanks
It's right here: ssh://h...@hg.python.org/repos/distutils2
Cheers,
Dirkjan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
2010/2/22 sstein...@gmail.com :
> The checkout URL for non-ssh read-only access is:
>
> http://hg.python.org/distutils2/
>
> in case anyone else is searching for it.
Right. As Maciej asked about this, let's discuss it here: there are
currently no emails for these repositories. I'd like to g
On Mon, Feb 22, 2010 at 15:42, Thomas Wouters wrote:
> It would be http://hg.python.org/benchmarks (http, not ssh; no username; no
> '/repos' toplevel directory.)
Correct.
Another todo is to get commit mails; I'm currently working on that.
Cheers,
Dirkjan
__
On Mon, Feb 22, 2010 at 16:09, Collin Winter wrote:
> So the consensus is that 2to3 should be pulled out of the main Python
> tree? Should the 2to3 hg repository be deleted, then?
Wouldn't the former be reason to officialize the hg repository,
instead of deleting it?
Cheers,
Dirkjan
___
On Mon, Feb 22, 2010 at 16:06, "Martin v. Löwis" wrote:
> I think sending them there "for now" is fine; in the long term, I
> propose to add an X-hgrepo header to the messages so that people can
> filter on that if they want to.
We get the X-Hg-Notification header (which has the changeset ID) for
On Mon, Feb 22, 2010 at 17:05, Collin Winter wrote:
> Sorry, I meant "pull from". I want an updated snapshot of 2to3 for the
> benchmark suite, and I'm looking for the best place to grab it from.
Well, the server that has all the stuff for doing the conversions has
annoyingly been down for about
On Mon, Feb 22, 2010 at 18:38, Martin Geisler wrote:
> My dissertation is due this Friday(!), so I will not have much time to
> look at EOL issues this week (as usual). But please give it a spin
> anyway and let us hear what you think!
I've got about 48 more hours of PyCon sprints ahead of me, so
On Tue, Feb 23, 2010 at 00:55, "Martin v. Löwis" wrote:
> Ah, this shouldn't be used at all for anything (except for studying how
> Mercurial works). Along with the cpython repository, it is Dirkjan's
> test conversion. Even if it survived the ultimate migration (which it
> probably won't), it wou
On Tue, Feb 23, 2010 at 00:57, "Martin v. Löwis" wrote:
> Can I use that to filter out distutils2 commits?
Well, I don't think we'll do commit emails for distutils2 or
unittest2, only for benchmarks (to python-checkins, anyway). I'll make
sure that you can filter something out by repository.
Che
On Tue, Feb 23, 2010 at 01:06, "Martin v. Löwis" wrote:
> I thought we decided not to have a 2to3 repository at all, but let this
> live in the Python trunk exclusively.
That would be fine with me, I just remembered that Benjamin would like
to start using hg sooner and having it as a separate rep
2010/2/23 Tarek Ziadé :
> Why is that ? I do want them as much as someone else would want the
> benchmarks ones I suppose.
>
> The whole subversion repository (including the sandbox) is sending
> mails to python-checkins, so I think we need to have the same policy
> here if possible, and use for ex
2010/2/23 Tarek Ziadé :
> Note sure what do you mean by doubts. I have no doubts I want to
> receive those emails to work on this code ;)
Some of the other committers didn't think they wanted email on
python-checkins from all the projects that will ever be hosted on
hg.python.org, so there should
On Tue, Feb 23, 2010 at 08:32, Barry Warsaw wrote:
> I think we should have commit emails for all projects hosted on
> hg.python.org. Those emails should perhaps go to different mailing lists, but
> post-commit emails are a great way for community members to follow the
> developments of our vario
First off, this was just a first sample, it was by no means the
definitive format.
Second, the diffs are already back, in the next message (this first
one was per changegroup, not per changeset -- new ones will be per
changeset).
On Thu, Mar 4, 2010 at 21:20, Brett Cannon wrote:
> 1) I miss not
On Thu, Mar 4, 2010 at 22:44, Benjamin Peterson wrote:
> +1 to bringing back affected files. It helps tell at a glance whether
> a changeset is interesting or not.
Do they need to be in the subject, or would it be fine to have them in
the message?
Cheers,
Dirkjan
___
On Thu, Mar 18, 2010 at 22:38, Terry Reedy wrote:
> Having gotten that far, I think this might be worth referencing in new dev
> docs.
Will do. I finally read hginit yesterday, after having seen people
rave about it on twitter for a few weeks, and it's a very friendly
introduction.
Cheers,
Dirk
On Tue, Mar 23, 2010 at 15:50, Brian Curtin wrote:
> Having been active in bug triage and patch writing/reviewing since late
> 2009, it was suggested in the python-dev IRC channel that I request commit
> access to the repository. I'm primarily a Windows user and have worked with
> many of the othe
On Tue, Apr 27, 2010 at 23:55, Nick Coghlan wrote:
> I believe the more important part of Barry's suggested change here is
> requiring a link to the archived message (usually from python-dev) where
> the PEP was accepted (be it directly by you as BDFL, or by consensus
> from a "sufficient" number
On Fri, Apr 30, 2010 at 21:09, Barry Warsaw wrote:
>>Though maybe it should be called Conclusion instead of Accepted and
>>used for Rejected PEPs, as well?
>
> Good point. What do you think about 'Resolution'?
Fine with me.
Cheers,
Dirkjan
___
Python
On Tue, May 4, 2010 at 14:41, Antoine Pitrou wrote:
> I think we should reindent all 3 branches. Most of the work can probably be
> scripted (str.replace("\t", " " * 4)), and then a visual pass is necessary to
> fix vertical alignments and the like.
If the script is robust enough, I can run it as
On Sun, May 23, 2010 at 12:15, Brian Quinlan wrote:
> I doubt it. Simple modules are unlikely to develop a following because it is
> too easy to partially replicate their functionality. urlparse and os.path
> are very useful modules but I doubt that they would have been successful on
> PyPI.
simp
On Sun, May 23, 2010 at 12:51, Antoine Pitrou wrote:
> I disagree that a stdlib module is a dead module. It is perfectly
> possible to augment the API with new functionality without breaking
> compatibility. You can also deprecate old APIs if you want.
Right, it wasn't intended as that harsh... b
On Wed, Jun 9, 2010 at 13:40, Antoine Pitrou wrote:
> No, I don't think so. If I'm using hex "encoding", it's because I want
> to see a text representation of some arbitrary bytestring (in order to
> display it inside another piece of text, for example).
> In other words, the purpose of hex is pre
It looks like simplejson 2.1.0 and 2.1.1 have been released:
http://bob.pythonmac.org/archives/2010/03/10/simplejson-210/
http://bob.pythonmac.org/archives/2010/03/31/simplejson-211/
It looks like any changes that didn't come from the Python tree didn't
go into the Python tree, either.
I guess w
On Thu, Jul 1, 2010 at 14:09, Dan Buch wrote:
> Does anybody know if there's already an issue tracking the failure
> so that volunteers can better reproduce the issue? Is a full checkout
> of /projects/python via hgsubversion all that's required, perhaps?
I work from a full svnsync of the projec
On Thu, Jul 1, 2010 at 14:52, anatoly techtonik wrote:
> Primary concern is that will happen with central Subversion
> repository. There are a plenty of private tools and automated scripts
> that were written to work with central Subversion repository, so it is
> important that central Subversion
On Thu, Jul 1, 2010 at 15:23, Dan Buch wrote:
> I assume having such a tarball available would be a good thing, but what
> do I know!? :)
I'm putting one up. I'll email you the address privately in order to
preserve some bandwidth. Anyone else who wants a copy: just email me.
> Are your steps fo
On Thu, Jul 1, 2010 at 16:31, Daniel Stutzbach
wrote:
> The hg-git tool allows Mercurial and git to interoperate, so that's not as
> much of an issue as it once was. It's geared toward using a Mercurial
> client to talk to a git server, but I'm told it can work the other way
> around with a bit o
On Thu, Jul 1, 2010 at 16:31, Daniel Stutzbach
wrote:
> Was there ever any discussion about hosting the central repository on a site
> such as bitbucket or github? I tried searching the python-dev archives but
> was unable to find much.
> Anyway... assuming there's a at least a clone of the centr
On Fri, Jul 2, 2010 at 02:08, Stephen J. Turnbull wrote:
> No, you don't. You make links to 200MB+ (unless you're on Windows,
> where I don't know how this works). This is much cheaper than
> copying, though not as cheap as in git. I don't hesitate to make
> branches in Mercurial.
It can still
On Fri, Jul 2, 2010 at 15:21, Antoine Pitrou wrote:
>> I'd love to see a more detailed description of this, including why
>> someone new to Mercurial would choose one over the other.
>>
>> This information really belongs in www.python.org/dev/ rather than
>> only in the mailing list.
>
> I'm not s
On Fri, Jul 2, 2010 at 16:17, anatoly techtonik wrote:
> As PEP 384 says - the transition is mostly to make lives of outside
> contributors easier. Core developers can wait for a while.
I think a lot of the core developers also want this because it makes
their lives better.
Also, several people
On Sat, Jul 3, 2010 at 12:53, Stephen J. Turnbull wrote:
> The point of submodules a la git is subtly different. It is that you
> can mix and match *known versions* of the modules. So, eg, in order
> to work on recent urllib, maybe you need a recent *but stable* email
> but you don't want any of
On Wed, Jul 7, 2010 at 01:47, anatoly techtonik wrote:
> That would be nice to hear about in more detail. As I understand there
> is no place where it is described. I already see +1 from Fred Drake
> and another +1 from Steve Holden down the thread.
>
> However, Antoine Pitrou,
On Tue, Jul 13, 2010 at 00:11, "Martin v. Löwis" wrote:
There's a one-to-one mapping somewhere.
>>>
>>> Unfortunately, no: we don't have email addresses of all committers.
>>
>> What about the python-committers mailing list? That has at least all
>> the active ones, correct?
>
> Probably. Als
This is getting a little off-topic, but let me just respond to this...
On Tue, Jul 13, 2010 at 22:10, Barry Warsaw wrote:
> Does Mercurial have a similar feature? If so, I would suggest that we enable
> that and require committers to use registered gpg keys to sign their commits.
> We'd always h
On Tue, Jul 13, 2010 at 23:22, Nick Coghlan wrote:
> No, I meant push. There's a separate discussion where it was pointed
> out that publishing each commit as a separate email makes
> python-checkins even chattier than it is already (this point came up
> after Tarek pushed a distutils2 changeset c
On Wed, Jul 14, 2010 at 10:15, Georg Brandl wrote:
> I also don't think we will see pushes like Tarek's 100+ one very often for
> Python. Usually changes will be bug fixes, and unless the committer is
> offline I expect them to be pushed immediately.
Depends. If we do feature branches in separat
On Wed, Jul 21, 2010 at 17:11, Tim Golden wrote:
> The Mercurial migration should move forward once Dirkjan has finished work
> on his thesis. Martin insisted that a for-real repository would have to be
> set up so that people can really see how it would work. An outstanding issue
> in hg-svn prev
On Wed, Jul 21, 2010 at 19:38, Ian Bicking wrote:
> From what I've been able to tell from afar, I strongly suspect PyPI's
> downtimes would be greatly reduced with a move to mod_wsgi (currently it is
> using mod_fcgi, and most downtime is solved with an Apache restart --
> mod_wsgi generally recov
On Tue, Aug 3, 2010 at 07:01, Ray Allen wrote:
> Is the tracker OK now?
Works for me.
Cheers,
Dirkjan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opt
On Wed, Aug 4, 2010 at 11:16, Antoine Pitrou wrote:
> I would advocate a system were people are encouraged to take
> responsibility of the problems they introduce when committing changes.
> Of course, there are sometimes situations where it's not possible
> (triggering platform-specific oddities,
On Tue, Sep 7, 2010 at 01:04, Antoine Pitrou wrote:
> What is needed in order to have write (i.e. push) access to the
> hg.python.org repositories?
> What are the URLs (for example for the "benchmarks" repository)?
IIRC you just need to have your public key on there, and you'll have
commit access
On Tue, Sep 7, 2010 at 10:11, Georg Brandl wrote:
> To be a bit more precise, having a public key on file for SVN commits is
> enough,
Not exactly, hg uses a separate keystore, so it might not have some of
the newer keys.
> and your URI is
>
> ssh://h...@hg.python.org/repos/benchmarks
>
> (That
On Tue, Sep 7, 2010 at 16:38, Antoine Pitrou wrote:
> Could push notification be added for the benchmarks repo?
> I think the python-checkins list would be an appropriate recipient for
> the e-mails (the repo has a low activity).
Fine with me, if the list agrees.
Cheers,
Dirkjan
___
On Wed, Sep 15, 2010 at 22:46, Brett Cannon wrote:
> Both the RM and BDFL agree that Python 3.2b1 should be held up until
> we settle this wsgi matter. That makes it a question of how to settle
> it.
I think that's a very good goal. Given all the times it's come up on
the Web-SIG list (I even tri
On Wed, Sep 15, 2010 at 21:18, P.J. Eby wrote:
> If I were to offer a suggestion to a PEP author or dictator wanting to get
> something out ASAP, it would probably be to create a compromise between the
> "flat" model (my personal favorite) and the mod_wsgi model, as an addendum
> to PEP 333. Spec
On Thu, Sep 23, 2010 at 08:40, Georg Brandl wrote:
> Of course, we might consider a separate HG repository (I'm all in favor
> of many small repos, instead of a gigantic sandbox one).
+1.
Cheers,
Dirkjan
___
Python-Dev mailing list
Python-Dev@python.o
On Thu, Sep 23, 2010 at 16:56, Guido van Rossum wrote:
> I want to believe your theory (since I also have a feeling that some
> wiki pages feel less trustworthy than others) but my own use of
> Wikipedia makes me skeptical that this is all there is -- on many
> pages on important topics you can cl
Hi all,
I've recently been working on the conversion more (since my thesis got
finished). I finally wrote the script that splits the release branches
from the feature branches, so that we can include the former in the
main repository and keep the latter in separate clones as needed.
Next, I wanted
On Sun, Sep 26, 2010 at 13:40, "Martin v. Löwis" wrote:
> This one can go as well. In general, I propose to remove all tags which
> aren't copies of trunk or some branch (i.e. tagging only a part of the
> Python source tree). I suppose hg can't represent that adequately,
> anyway (they often come
On Sun, Sep 26, 2010 at 13:36, Paul Moore wrote:
> Hmm, I can't find the one I was thinking of. GetLongFileName correctly
> sets the case of all but the final part, and FindFile can be used to
> find the last part, but that's not what I recall.
>
> GetFinalPathNameByHandle works, and is documented
On Mon, Sep 27, 2010 at 17:28, Barry Warsaw wrote:
> I do think we should keep a mapping from new to old though. If that's not
> possible within the hg repository, can we at least generate a text file or
> some such and commit that?
I'm planning an extension so that at least the web interface wi
On Wed, Sep 29, 2010 at 03:13, Steve Holden wrote:
> I see that Atlassian have just taken over BitBucket, the Mercurial
> hosting company. IIRC Atlassian offered to host our issue tracking on
> JIRA, but in the end we decided to eat our own dog food and went with
> roundup.
>
> I'm wondering if th
On Wed, Sep 29, 2010 at 08:58, Brett Cannon wrote:
> Looking at their pricing model, we don't need permission; public repos
> can have unlimited contributors. Plus bitbucket supports CNAMEs so we
> would also be able to still have hg.python.org for accessing the
> repos.
>
> The trick would be man
Okay, so let's summarize this thread so far:
Martin is in favor of removing some tags (certainly partial ones), but
is -0 on renaming them.
Tres is in favor of renaming release tags.
Georg advocates removing non-release tags, and doesn't care much about renaming.
Barry would like to clean up relea
On Wed, Sep 29, 2010 at 11:35, Victor Stinner
wrote:
> Can't we rewrite the history when converting from svn to hg to use real names
> instead of logins?
I've been doing that since the start, look at the test repo on hg.p.o.
Cheers,
Dirkjan
___
Python
On Wed, Sep 29, 2010 at 14:27, Benjamin Peterson wrote:
> It seems like a slippery slope. Sometimes you really don't care like
> when you're just hacking together a quick script.
Yeah, I often don't close files in scripts that I know are short
running or only ever open one or two files, and I don
On Wed, Sep 29, 2010 at 16:43, Barry Warsaw wrote:
> Do we expect Mercurial to require more, less, or about the same amount of
> babysitting as the current Subversion repository? I would think no more and
> Subversion hasn't been much of a problem.
Yeah, should be about the same.
Cheers,
Dirkj
On Wed, Sep 29, 2010 at 20:32, Guido van Rossum wrote:
> I would like to recommend that the Python core developers start using
> a code review tool such as Rietveld or Reviewboard. I don't really
> care which tool we use (I'm sure there are plenty of pros and cons to
> each) but I do think we shou
On Tue, Oct 5, 2010 at 11:19, "Martin v. Löwis" wrote:
> Would anybody be willing to run a build slave on a machine that
> you have available? The main requirement is that the machine is
> always connected to the internet, although not necessarily with
> a fixed IP address.
I can probably run a b
On Tue, Oct 5, 2010 at 17:06, "Martin v. Löwis" wrote:
>> I can probably run a build slave on one of my boxes (Gentoo, Athlon 64
>> x2). Where are the setup docs?
>
> http://wiki.python.org/moin/BuildBot
Cool, can you get me username/passwd?
Cheers,
Dirkjan
_
On Thu, Oct 7, 2010 at 00:53, Trent Mick wrote:
> 1. Change `difflib.unified_diff` to emit:
>
> ['--- \n', '+++ \n', '@@ -1,3 +1,3 @@\n', ' one\n', ' two\n',
> '-three\n', '\ No newline at end of file', '+trois\n', '\ No newline
> at end of file']
>
> instead of:
>
> ['--- \n', '+++ \n',
On Fri, Oct 8, 2010 at 09:05, Tarek Ziadé wrote:
> The feedback I received for this is pretty clear: people want a single
> script that can be called directly. e.g.
>
> $ distutils2 depgraph
> $ distutils2 install
> $ distutils2 run command
>
> Fair enough, I can add that script in the project and
2010/10/8 Fred Drake :
> Georg:
>> What happened to "python setup.py action"? Or is this a step towards
>> not requiring setup.py at all?
>
> I'm in favor of add a top-level setup module that can be invoked using
> "python -m setup ...". There will be three cases:
>
> - d2 projects without a setu
On Fri, Oct 8, 2010 at 15:22, Tarek Ziadé wrote:
> Mmm.. setup.py is gone in D2, and setup.py will be the marker of d1.
So, sorry for backing up to this, but isn't it true that many projects
do custom stuff in their setup.py that they wouldn't be able to do in
setup.cfg? Is the goal really to mak
Okay, we're getting somewhere here.
I've been conferring with Georg on when we can do the conversion. He's
done some testing with the buildbot setup, which seems to be mostly
done. He also completed preliminary ports of the hooks used in the SVN
repository. He managed to convince me that we're at
101 - 200 of 284 matches
Mail list logo
