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 managing accounts. I would assume either everyone would need bitbucket accounts to add as contributors to a repo, or a dummy python-dev user account would be created where select core devs could add SSH keys to the python-dev user account (although I think the latter would destroy the commit history in terms of who made what change as I suspect bitbucket does it based on the bitbucket account and not one's .hgrc info although I could be wrong). Without knowing how this would be handled I can't really comment.

Yeah, you can just add all the SSH keys to a single account. And usernames are always taken from the hgrc. Remember, the changeset authors are put into the changeset at commit time, not at push time, and the changeset ID depends on it, so you could never have a remote host changing the usernames without the history changing. Still, I think the flexibility of self-hosting (in terms of hooks and extension -- for example the one that would allow lookup by SVN rev) should win out here. Cheers, Dirkjan

On 9/29/2010 6:32 AM, Ben Finney wrote:

Dirkjan Ochtman writes:

...

Still, I think the flexibility of self-hosting (in terms of hooks and extension -- for example the one that would allow lookup by SVN rev) should win out here.

Not only the flexibility, but the autonomy. Hosting the source code on systems either paid for by PSF funds or donated to the PSF will allow all decisions about how the VCS repositories are administrated to be made without deferring to the repository provider as a separate entity.

Or, more briefly: it's better for the PSF to be as much in control of the decisions about what happens to the VCS repositories as possible.

That's true, but we also have to balance that against the resources it takes to develop and manage our own hosting solutions. I'm not trying to push one way or the other (and Dirkan's points about tailored commit hooks seems compelling); I simply want to make sure that as much developer time as possible is actually spent developing Python rather than supporting the development effort in various ways that aren't as directly productive. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/

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

On Wed, 29 Sep 2010 09:03:29 +0200 Dirkjan Ochtman wrote:

Anyway, I don't think using Bitbucket buys us much. It could be nice to keep a mirror there for redundancy and because it might make contributing slightly easier for non-committers, but it won't allow doing all kinds of custom hooks the way we could do with hg.p.o, AFAICT.

Using Bitbucket seems mainly useful if you need the whole suite of services (issue tracker, wiki, etc.). Also, I find the Bitbucket UI horrible. Better than Launchpad probably, but still... Regards Antoine.

Am 29.09.2010 09:03, schrieb Dirkjan Ochtman:

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 they'd be similarly interested in supporting our Hg server. Or is self-hosting the only acceptable solution? From recent mail it looks likes we may be up and running on Hg fairly soon.

Don't know about acceptable, but as far as I know hosting Mercurial repositories doesn't require as much work as hosting Roundup instances (which the Mercurial project also has). I wouldn't mind maintaining hg.python.org, and there are probably other devs that could also easily get involved.

Anyway, I don't think using Bitbucket buys us much. It could be nice to keep a mirror there for redundancy and because it might make contributing slightly easier for non-committers, but it won't allow doing all kinds of custom hooks the way we could do with hg.p.o, AFAICT.

Agreed on both counts. Bitbucket will be a good solution for non-core developers to host their clones and branches, and I'm sure there will be a mirror of the main Python repo somewhere. But as you say, hosting Mercurial is very easy, and doesn't require constant administration. The argument of hooks is a very strong one in favor of hg.python.org. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

On Wed, Sep 29, 2010 at 2:36 PM, wrote:

On 01:13 am, steve@holdenweb.com 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 they'd be similarly interested in supporting our Hg server. Or is self-hosting the only acceptable solution? From recent mail it looks likes we may be up and running on Hg fairly soon.

I know of two medium sized projects (smaller than CPython) that are switching away from BitBucket's free services because of their poor reliability.

Me too, but I am pretty sure the reliability is going to drastically change in the upcoming months. If Atlassian took over this probably means Bitbucket will have more people to work on the project and some help from the Atlassian Ops. That's really a good news ! Although, I am also -1 because of the hooks management issues that were raised -- Tarek Ziadé | http://ziade.org

Do we expect Mercurial to require more, less, or about the same amount of babysitting as the current Subversion repository?

The ongoing effort is to manage write access; this is not going to change with Mercurial. With a hosted service, you still need someone who gives write permissions to people. What you gain is not having to deal with lost credentials (forgotten passwords, new SSH keys). We *could* of course setup a web-based user management on python.org as well so committers can upload their SSH keys over the web, however, the current approach has not produced much problems. For Mercurial (or any other VCS), there is also an upfront effort to setup the system, which is primarily data conversion and hooks. Expect increased activity in creating hooks for one year after the switchover. Of course, with a hosted service, you often can't run hooks at all, so the effort to write them is also reduced :-) Regards, Martin

On Wed, Sep 29, 2010 at 5:41 PM, Daniel Stutzbach wrote:

Obviously, it would not be possible to write hooks that reject changesets

Of course, this is one of the more interesting ways to use hooks. Since there's no current expectation that running our own will be a problem, why don't we convert and see how it goes? If we discover problems doing so and think a hosted solution would solve them, we can reconsider then.   -Fred -- Fred L. Drake, Jr.    <fdrake at acm.org> "A storm broke loose in my mind."  --Albert Einstein