Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Nick Coghlan]

On 24 Nov 2014 10:41, "Donald Stufft"  wrote:
>
>
> > On Nov 23, 2014, at 6:57 PM, Steven D'Aprano 
wrote:
> >
> > On Sun, Nov 23, 2014 at 08:55:50AM -0800, Guido van Rossum wrote:
> >
> >> But I strongly believe that if we want to do the right thing for the
> >> long term, we should switch to GitHub.
> >
> > Encouraging a software, or social, monopoly is never the right thing for
> > the long term.
> >
> > http://nedbatchelder.com/blog/201405/github_monoculture.html
>
> I don’t think this is really all that big of a deal. If we want to move
> off of Github doing so is easy.

It's only easy to leave if you never adopt any GitHub-only services like
Travis CI. It's the same lockin play as the one Google uses: make it easy
for people to move their data, so they're less likely to notice you're
locking them in with proprietary APIs and ecosystems instead.

You unlikely to see significant amounts of VC funding pouring into a
company unless the investors see a possible chance to extract monopoly
rents at some point in the future.

Cheers,
Nick.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Nick Coghlan]

> On Nov 23, 2014, at 1:49 AM, Nick Coghlan wrote:
>>>
>>> I took the git knowledge I acquired by necessity at Red Hat and
>>> figured out how to apply it to hg. All the same features are there in
>>> hg, they're just switched off by default (mainly because the core
>>> Mercurial devs are adamant that any potentially history destroying
>>> operation in a version control system must be opt-in).
>
> If you could find the time to write up something about that I'm sure it would 
> be helpful.  :)

The main thing is to enable some of the extensions mentioned in
http://mercurial.selenic.com/wiki/GitConcepts#Command_equivalence_table
by adding the appropriate entries to ~/.hgrc. A subset of my own
extension set:

==
[extensions]
rebase =
share =
eol =
histedit =
record =
purge =
==

Share (multiple working directories from a single clone) is nice for a
multi-branch project like CPython, while record allows selective
commits, rebase allows changeset rebasing (as you might expect),
histedit allows interactive history editing (akin to git's interactive
rebasing), and pure allows deleting commits entirely. eol is the
extension for Windows end of line handling that CPython needs.

Several of those are off by default due to Mercurial's policy that
anything which risks losing data should be off by default - messy
history is considered preferable to potentially losing changes you
didn't mean to destroy. git, by contrast, is happy to let users
destroy history, and considers it their own fault if they mess it up
and lose content irrevocably - thus the plethora of "how to use git
safely" guides, while there's a relative dearth of "how to enable
history modification in Mercurial" guides.

The Mercurial team's preferred solution to history modification is
changeset evolution, which also version controls any history editing
operations so they can be reliably communicated to other users of a
shared repo: http://evolution.experimentalworks.net/doc/user-guide.html

While that's officially still experimental, it's unlikely to pose
significant hazards to anyone coming to Mercurial from git - git's
default mode of operation is far more cavalier regarding repository
history than evolve will ever be.

Another aspect that can be somewhat annoying is the terminology
conflict between branches in the git sense and bookmarks vs named
branches in the Mercurial sense. In Mercurial, commits made on a
branch permanently remember which branch they were made on - you can
see in the CPython history, for example, whether a particular commit
was made to the 2.7 branch, or the 3.3 branch, etc, just by looking at
the commit in isolation. Mercurial bookmarks and git branches, by
contrast, are just references to a particular commit that represents
the current head of a particular line of development - to find out if
a particular commit is on that line of development, you have to trace
the commit graph backwards to see if it appears.

For a while, Mercurial was also missing support for git-style revision
shorthands (you needed an extension to add them), but these days you
can do things like "hg diff -r tip^" or "hg diff -r 'p1()^'" to
specify relative revset references (while still retaining the full
flexibility of Mercurial's programmatic revset syntax if you need it).

(Speaking of which, I remembered one key thing which would likely be
broken by a switch in the underlying DVCS: the Reitveld/Roundup
integration)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Paul Moore]

On 24 November 2014 at 10:20, Nick Coghlan  wrote:
> Another aspect that can be somewhat annoying is the terminology
> conflict between branches in the git sense and bookmarks vs named
> branches in the Mercurial sense.

This is probably the thing that hurts me most in git/hg translation.
In git, I routinely create branches, play with them, then throw them
away (either once they get integrated, or when I decide they are a bad
idea). It seems to me to be *much* harder to get that lightweight
behaviour in hg - if I create a PR for a hg project that isn't
accepted, how do I delete it from my clone? In a way that means it
won't reappear when I push/pull from my other PC, where I forgot to
*also* delete it? Does the answer to that depend on whether I used a
bookmark or a branch (and relatedly, which should I use)?

Maybe it's also more complicated than it seems on git, but cleaning up
experiments seems much easier to me on git.

Not that we're getting offtopic here at all, of course... ;-)

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Ben Finney]

Nick Coghlan  writes:

> Are you volunteering to write a competing PEP for a migration to git
> and GitHub?

Anyone who does decide to propose either Git or GitHub for hosting
Python resources: Please don't conflate the two.

Git is a community-supported free-software DVCS system with many viable
hosting platforms and providers.

GitHub is one proprietary hosting service with features that encourage
vendor lock-in, and as Barry Warsaw pointed out it is not answerable to
the PSF nor under the PSF's control. There are other hosting solutions
without these problems.

Everyone here already knows this distinction at some level, but it's far
too common to see people assume that an argument in favour of Git will
also be a compelling case for GitHub. It isn't, and the case for the
latter needs to be made quite separately from the case for the former.

No, I'm not offering to write such a PEP either. I'm requesting that we
recognise that a promotion of GitHub needs to account for its downsides
too, and needs to promote its specific benefits separately from the
benefits of Git.

-- 
 \“There are no significant bugs in our released software that |
  `\ any significant number of users want fixed.” —Bill Gates, |
_o__)   1995-10-23 |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Donald Stufft]

> On Nov 24, 2014, at 6:44 AM, Ben Finney  wrote:
> 
> Nick Coghlan  writes:
> 
>> Are you volunteering to write a competing PEP for a migration to git
>> and GitHub?
> 
> Anyone who does decide to propose either Git or GitHub for hosting
> Python resources: Please don't conflate the two.
> 
> Git is a community-supported free-software DVCS system with many viable
> hosting platforms and providers.
> 
> GitHub is one proprietary hosting service with features that encourage
> vendor lock-in, and as Barry Warsaw pointed out it is not answerable to
> the PSF nor under the PSF's control. There are other hosting solutions
> without these problems.
> 
> Everyone here already knows this distinction at some level, but it's far
> too common to see people assume that an argument in favour of Git will
> also be a compelling case for GitHub. It isn't, and the case for the
> latter needs to be made quite separately from the case for the former.
> 
> No, I'm not offering to write such a PEP either. I'm requesting that we
> recognise that a promotion of GitHub needs to account for its downsides
> too, and needs to promote its specific benefits separately from the
> benefits of Git.
> 

In many cases Github is git’s killer feature which is why you see a lot
of people equate the two. It’s not unusual to see a project switch away
from X to git entirely so they can use Github.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Nick Coghlan]

On 24 November 2014 at 22:01, Donald Stufft  wrote:
>> On Nov 24, 2014, at 6:44 AM, Ben Finney  wrote:
>> No, I'm not offering to write such a PEP either. I'm requesting that we
>> recognise that a promotion of GitHub needs to account for its downsides
>> too, and needs to promote its specific benefits separately from the
>> benefits of Git.
>>
>
> In many cases Github is git’s killer feature which is why you see a lot
> of people equate the two. It’s not unusual to see a project switch away
> from X to git entirely so they can use Github.

And this is why the "you can still get your data out" argument doesn't
make any sense - if you aren't planning to rely on the proprietary
APIs, GitHub is just a fairly mundane git hosting service, not
significantly different in capabilities from Gitorious, or RhodeCode,
or BitBucket, or GitLab, etc. So you may as well go with one of the
open source ones, and be *completely* free from vendor lockin.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Donald Stufft]

> On Nov 24, 2014, at 7:09 AM, Nick Coghlan  wrote:
> 
> On 24 November 2014 at 22:01, Donald Stufft  wrote:
>>> On Nov 24, 2014, at 6:44 AM, Ben Finney  wrote:
>>> No, I'm not offering to write such a PEP either. I'm requesting that we
>>> recognise that a promotion of GitHub needs to account for its downsides
>>> too, and needs to promote its specific benefits separately from the
>>> benefits of Git.
>>> 
>> 
>> In many cases Github is git’s killer feature which is why you see a lot
>> of people equate the two. It’s not unusual to see a project switch away
>> from X to git entirely so they can use Github.
> 
> And this is why the "you can still get your data out" argument doesn't
> make any sense - if you aren't planning to rely on the proprietary
> APIs, GitHub is just a fairly mundane git hosting service, not
> significantly different in capabilities from Gitorious, or RhodeCode,
> or BitBucket, or GitLab, etc. So you may as well go with one of the
> open source ones, and be *completely* free from vendor lockin.

I don’t really agree unless what you’re saying is that the reason it
doesn’t make any sense is because you probably won’t want to get your
data out because Github’s features are compelling enough that you
don’t want to lose them.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Donald Stufft]

> On Nov 24, 2014, at 4:12 AM, Nick Coghlan  wrote:
> 
> 
> On 24 Nov 2014 10:41, "Donald Stufft"  > wrote:
> >
> >
> > > On Nov 23, 2014, at 6:57 PM, Steven D'Aprano  > > > wrote:
> > >
> > > On Sun, Nov 23, 2014 at 08:55:50AM -0800, Guido van Rossum wrote:
> > >
> > >> But I strongly believe that if we want to do the right thing for the
> > >> long term, we should switch to GitHub.
> > >
> > > Encouraging a software, or social, monopoly is never the right thing for
> > > the long term.
> > >
> > > http://nedbatchelder.com/blog/201405/github_monoculture.html 
> > > 
> >
> > I don’t think this is really all that big of a deal. If we want to move
> > off of Github doing so is easy.
> 
> It's only easy to leave if you never adopt any GitHub-only services like 
> Travis CI. It's the same lockin play as the one Google uses: make it easy for 
> people to move their data, so they're less likely to notice you're locking 
> them in with proprietary APIs and ecosystems instead.
> 
> You unlikely to see significant amounts of VC funding pouring into a company 
> unless the investors see a possible chance to extract monopoly rents at some 
> point in the future.
> 
> Cheers,
> Nick.
> 


Dropping those services is not harder than running those services on our own 
anyways. It’s unlikely, for instance, that CPython itself would ever be able to 
use Travis so if we did move to Github and at some point in the future want to 
move away from Github we’d simply be reverting to the state we’re in now. We 
wouldn’t be worse off other than we’d have experienced something better than 
what we have now. I suppose purposely hobbling ourselves so we never get used 
to something better is a legitimate way to manage things.

It’s not different than saying spam filtering is a “vendor lockin” on gmail 
because if you want to switch away from it in the future you’ll have to set up 
your own spam filtering.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Donald Stufft]

> On Nov 24, 2014, at 2:25 AM, Nick Coghlan  wrote:
> 
> On 24 November 2014 at 02:55, Brett Cannon  wrote:
>> On Sun Nov 23 2014 at 6:18:46 AM Nick Coghlan  wrote:
>>> Those features are readily accessible without changing the underlying
>>> version control system (whether self-hosted through Kallithea or externally
>>> hosted through BitBucket or RhodeCode). Thus the folks that want to change
>>> the version control system need to make the case that doing so will provide
>>> additional benefits that *can't* be obtained in a less disruptive way.
>> 
>> I guess my question is who and what is going to be disrupted if we go with
>> Guido's suggestion of switching to GitHub for code hosting? Contributors
>> won't be disrupted at all since most people are more familiar with GitHub
>> vs. Bitbucket (how many times have we all heard the fact someone has even
>> learned Mercurial just to contribute to Python?). Core developers might be
>> based on some learned workflow, but I'm willing to bet we all know git at
>> this point (and for those of us who still don't like it, myself included,
>> there are GUI apps to paper over it or hg-git for those that prefer a CLI).
>> Our infrastructure will need to be updated, but how much of it is that
>> hg-specific short of the command to checkout out the repo? Obviously
>> Bitbucket is much more minor by simply updating just a URL, but changing `hg
>> clone` to `git clone` isn't crazy either. Georg, Antoine, or Benjamin can
>> point out if I'm wrong on this, maybe Donald or someone in the
>> infrastructure committee.
> 
> Are you volunteering to write a competing PEP for a migration to git and 
> GitHub?
> 
> I won't be updating PEP 474 to recommend moving to either, as I don't
> think that would be a good outcome for the Python ecosystem as a
> whole. It massively undercuts any possible confidence anyone else
> might have in Mercurial, BitBucket, Rhodecode, Kallithea & Allura (all
> Python based version control, or version control hosting, systems). If
> we as the Python core development team don't think any of those are
> good enough to meet the modest version control needs of our support
> repos, why on earth would anyone else choose them?

If those project’s depend on CPython to pick them then they are doomed
because we can only pick one. If we pick Bitbucket than the core development
team must not think Rhodecode, Kallithea, & Allura is good enough so why
on earth would anyone choose them? Ditto for any of the other options.

> 
> In reality, I think most of these services are pretty interchangeable
> - GitHub's just been the most effective at the venture capital powered
> mindshare grab business model (note how many of the arguments here
> stem from the fact folks like *other* things that only interoperate
> with GitHub, and no other repository hosting providers - that's the
> core of the A18z funded approach to breaking the "D" in DVCS and
> ensuring that GitHub's investors are in a position to clip the ticket
> when GitHub eventually turns around and takes advantage of its
> dominant market position to increase profit margins).

You’ll see those arguments because the other argument is “softer”, Github
just plain works better than Bitbucket does.

> 
> That's why I consider it legitimate to treat supporting fellow Python
> community members as the determining factor - a number of the
> available options meet the "good enough" bar from a technical
> perspective, so it's reasonable to take other commercial and community
> factors into account when making a final decision.

Sure it’s completely reasonable to take that into account, I don’t think
“Not written in Python” should be a disqualifying statement though. We should
pick the best tool for the job.

> 
>> Probably the biggest thing I can think of that would need updating is our
>> commit hooks. Once again Georg, Antoine, or Benjamin could say how difficult
>> it would be to update those hooks.
> 
> If CPython eventually followed suit in migrating to git (as seems
> inevitable if all the other repos were to switch), then every buildbot
> will also need to be updated to have git installed (and Mercurial
> removed).
> 
>>> From my perspective, swapping out Mercurial for git achieves exactly
>>> nothing in terms of alleviating the review bottleneck (since the core
>>> developers that strongly prefer the git UI will already be using an
>>> adapter), and is in fact likely to make it worse by putting the greatest
>>> burden in adapting to the change on the folks that are already under the
>>> greatest time pressure.
>> 
>> That's not entirely true. If you are pushing a PR shift in our patch
>> acceptance workflow then Bitbucket vs. GitHub isn't fundamentally any
>> different in terms of benefit, and I would honestly argue that GitHub's PR
>> experience is better. IOW either platform is of equal benefit.
> 
> Yes, I agree any real benefit comes from the PR workflow, not from
> git. This is why I consider "written in Python"

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Wes Turner]

On Nov 24, 2014 3:12 AM, "Nick Coghlan"  wrote:
>
>
> On 24 Nov 2014 10:41, "Donald Stufft"  wrote:
> >
> >
> > > On Nov 23, 2014, at 6:57 PM, Steven D'Aprano 
wrote:
> > >
> > > On Sun, Nov 23, 2014 at 08:55:50AM -0800, Guido van Rossum wrote:
> > >
> > >> But I strongly believe that if we want to do the right thing for the
> > >> long term, we should switch to GitHub.
> > >
> > > Encouraging a software, or social, monopoly is never the right thing
for
> > > the long term.
> > >
> > > http://nedbatchelder.com/blog/201405/github_monoculture.html
> >
> > I don’t think this is really all that big of a deal. If we want to move
> > off of Github doing so is easy.
>
> It's only easy to leave if you never adopt any GitHub-only services like
Travis CI. It's the same lockin play as the one Google uses: make it easy
for people to move their data, so they're less likely to notice you're
locking them in with proprietary APIs and ecosystems instead.

- [ ] list of features ranked by stakeholder value
- [ ] pingbacks
- [ ] in-band build status
- [ ] tagging commits with #num
- [ ] web standards for integration (HTTP webhooks are the standards here)
... 'Zapier'

For this acquisition; is there a feature comparison matrix with
alternatives across the top and namespaced features along the side?

>
> You unlikely to see significant amounts of VC funding pouring into a
company unless the investors see a possible chance to extract monopoly
rents at some point in the future.
>
> Cheers,
> Nick.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] ubuntu buildbot

[Benjamin Peterson]

On Mon, Nov 24, 2014, at 00:33, David Bolen wrote:
> Yeah, it definitely needs it.  Historically it was intentional as my own
> servers were all on 8.04, but the last of those moved 12.04 last year.
> 
> I think there's already a 12.04 buildbot, so perhaps 14.04 would be
> better?  I do prefer sticking with an LTS.

14.04 would be good.

> 
> It'll need to move to 64-bit given the hosting environment, at least for
> the kernel.  I could do 32-bit userspace via multiarch if keeping a
> 32-bit
> buildbot in the mix is attractive.

It'd be nice to keep a 32-bit bot around.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Brett Cannon]

On Mon Nov 24 2014 at 2:25:30 AM Nick Coghlan  wrote:

> On 24 November 2014 at 02:55, Brett Cannon  wrote:
> > On Sun Nov 23 2014 at 6:18:46 AM Nick Coghlan 
> wrote:
> >> Those features are readily accessible without changing the underlying
> >> version control system (whether self-hosted through Kallithea or
> externally
> >> hosted through BitBucket or RhodeCode). Thus the folks that want to
> change
> >> the version control system need to make the case that doing so will
> provide
> >> additional benefits that *can't* be obtained in a less disruptive way.
> >
> > I guess my question is who and what is going to be disrupted if we go
> with
> > Guido's suggestion of switching to GitHub for code hosting? Contributors
> > won't be disrupted at all since most people are more familiar with GitHub
> > vs. Bitbucket (how many times have we all heard the fact someone has even
> > learned Mercurial just to contribute to Python?). Core developers might
> be
> > based on some learned workflow, but I'm willing to bet we all know git at
> > this point (and for those of us who still don't like it, myself included,
> > there are GUI apps to paper over it or hg-git for those that prefer a
> CLI).
> > Our infrastructure will need to be updated, but how much of it is that
> > hg-specific short of the command to checkout out the repo? Obviously
> > Bitbucket is much more minor by simply updating just a URL, but changing
> `hg
> > clone` to `git clone` isn't crazy either. Georg, Antoine, or Benjamin can
> > point out if I'm wrong on this, maybe Donald or someone in the
> > infrastructure committee.
>
> Are you volunteering to write a competing PEP for a migration to git and
> GitHub?
>

Been there, done that, got the PEP number. I'm just trying to speak from
the perspective of the person who drove us off of svn and on to hg (as well
as drove us off of SourceForge to our own workflow stack). I personally
just want a better workflow. As I said at the beginning, I read your PEPs
and talked to you about them at PyCon and I want something like that to
happen; push button patch acceptance along with CI of patches would go a
long way to making accepting patches easier. But as others have pointed
out, we just don't have the volunteer time to make them happen ATM, so I'm
willing to entertain moving to GitHub or Bitbucket or whatever to improve
our situation.


>
> I won't be updating PEP 474 to recommend moving to either, as I don't
> think that would be a good outcome for the Python ecosystem as a
> whole. It massively undercuts any possible confidence anyone else
> might have in Mercurial, BitBucket, Rhodecode, Kallithea & Allura (all
> Python based version control, or version control hosting, systems). If
> we as the Python core development team don't think any of those are
> good enough to meet the modest version control needs of our support
> repos, why on earth would anyone else choose them?
>
> In reality, I think most of these services are pretty interchangeable
> - GitHub's just been the most effective at the venture capital powered
> mindshare grab business model (note how many of the arguments here
> stem from the fact folks like *other* things that only interoperate
> with GitHub, and no other repository hosting providers - that's the
> core of the A18z funded approach to breaking the "D" in DVCS and
> ensuring that GitHub's investors are in a position to clip the ticket
> when GitHub eventually turns around and takes advantage of its
> dominant market position to increase profit margins).
>
> That's why I consider it legitimate to treat supporting fellow Python
> community members as the determining factor - a number of the
> available options meet the "good enough" bar from a technical
> perspective, so it's reasonable to take other commercial and community
> factors into account when making a final decision.
>
> > Probably the biggest thing I can think of that would need updating is our
> > commit hooks. Once again Georg, Antoine, or Benjamin could say how
> difficult
> > it would be to update those hooks.
>
> If CPython eventually followed suit in migrating to git (as seems
> inevitable if all the other repos were to switch), then every buildbot
> will also need to be updated to have git installed (and Mercurial
> removed).
>
> >> From my perspective, swapping out Mercurial for git achieves exactly
> >> nothing in terms of alleviating the review bottleneck (since the core
> >> developers that strongly prefer the git UI will already be using an
> >> adapter), and is in fact likely to make it worse by putting the greatest
> >> burden in adapting to the change on the folks that are already under the
> >> greatest time pressure.
> >
> > That's not entirely true. If you are pushing a PR shift in our patch
> > acceptance workflow then Bitbucket vs. GitHub isn't fundamentally any
> > different in terms of benefit, and I would honestly argue that GitHub's
> PR
> > experience is better. IOW either platform is of equal benef

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Donald Stufft]

> On Nov 24, 2014, at 11:28 AM, Brett Cannon  wrote:
> 
> On Mon Nov 24 2014 at 2:25:30 AM Nick Coghlan  > wrote:
>  
> That
> outcome would be the antithesis of the PSF's overall mission, 
> 
> This might be a little controversial, but the PSF's mission should not 
> influence a decision of python-dev. If we had to break a tie then yes, I 
> would choose the Python-based solution. But if a superior solution existed 
> and it just happened to not be written in Python I'm not going to sacrifice 
> productivity and the overall health of the project just to promote an 
> inferior tool because they happened to choose Python.
> 
> The only reason we didn't go with Jira for our issue tracker was because of 
> pressure to not go with a closed-source solution and I was promised 
> volunteers from the FSF to help manage our issue tracker (which never 
> materialized, BTW).

This is really what I’m trying to do but I’m apparently not getting my point 
across very well. I want us to pick the best tool for the job regardless of 
what language it’s written in. I just so happen to think that the best tool for 
the job in this case is Github.

> Yes, I object strongly to the use of GitHub when there are
> commercially supported services written in Python like BitBucket and
> RhodeCode available if we want to go the external hosting route, and
> other options like the RhodeCode derived Kallithea if we want to run a
> self-hosted forge. RhodeCode are even PSF sponsors - I'm sure they'd
> be willing to discuss the possibility of hosting core development
> repos on their service.
> 
> That's fine if they want to talk about free support, but being a PSF sponsor 
> should not play into it in the slightest, else it's like buying influence.

Agreed here too (even then, Github has been a PyCon sponsor for awhile and has 
even ran their own Python conference in the past). I think it’s kind of shitty 
to reject and demean someone who has supported the Python community through 
various means just because their primary language isn’t Python.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Donald Stufft]

> On Nov 24, 2014, at 2:25 AM, Nick Coghlan  wrote:
> 
> Are you volunteering to write a competing PEP for a migration to git and 
> GitHub?

If nobody steps up to do this (and another PEP isn’t accepted before then) I can
likely write something up over the upcoming holiday.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Wes Turner]

Is there snapshotting?

On Mon, Nov 24, 2014 at 10:44 AM, Donald Stufft  wrote:

>
> > On Nov 24, 2014, at 2:25 AM, Nick Coghlan  wrote:
> >
> > Are you volunteering to write a competing PEP for a migration to git and
> GitHub?
>
> If nobody steps up to do this (and another PEP isn’t accepted before then)
> I can
> likely write something up over the upcoming holiday.
>
> ---
> Donald Stufft
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com
>



-- 
Wes Turner
https://westurner.github.io/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Please reconsider PEP 479.

[Isaac Schwabacher]

On 11/23/14, Guido van Rossum  wrote:

> It wouldn't be so bad if we had the occasional generator author writing 
> "raise StopIteration" instead of "return" to exit from a generator. (We could 
> just add a recommendation against this to the style guide.) But the problem 
> is that an unguarded next() call also raises StopIteration. Sometimes this is 
> intentional (as in some itertools examples). But sometimes an unguarded 
> next() call occurs deep in the bowels of some code called by the generator, 
> and this situation is often hard to debug, since there is no stack track.

I'll admit I've only skimmed the massive volume of correspondence this PEP has 
generated, but it seems to me that this is the main argument for this change. I 
can only assume that your support for this PEP is informed by your experience 
building Tulip, but isn't this the kind of thing that can be accomplished with 
a warning? Then you can get the same behavior without even needing a __future__ 
import to protect code bases that expect StopIteration to propagate (which 
seems like the more elegant and natural thing to do, even if it is more 
error-prone).

ijs
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Berker Peksağ]

On Mon, Nov 24, 2014 at 6:36 PM, Donald Stufft  wrote:
>
> On Nov 24, 2014, at 11:28 AM, Brett Cannon  wrote:
>
> On Mon Nov 24 2014 at 2:25:30 AM Nick Coghlan  wrote:
>
>>
>> That
>> outcome would be the antithesis of the PSF's overall mission,
>
>
> This might be a little controversial, but the PSF's mission should not
> influence a decision of python-dev. If we had to break a tie then yes, I
> would choose the Python-based solution. But if a superior solution existed
> and it just happened to not be written in Python I'm not going to sacrifice
> productivity and the overall health of the project just to promote an
> inferior tool because they happened to choose Python.
>
> The only reason we didn't go with Jira for our issue tracker was because of
> pressure to not go with a closed-source solution and I was promised
> volunteers from the FSF to help manage our issue tracker (which never
> materialized, BTW).
>
>
> This is really what I’m trying to do but I’m apparently not getting my point
> across very well. I want us to pick the best tool for the job regardless of
> what language it’s written in. I just so happen to think that the best tool
> for the job in this case is Github.

For peps and devguide repos GitHub would be the best tool, but not for
Doc/ and CPython itself. I also agree that GitHub's big green merge
button works well for small or middle sized projects. We can just
press the merge button for pep and devguide repos, but for Doc/ I
think using GitHub or Bitbucket would be painful.

Currently, I do the following steps for a typo fix or a minor markup change:

* Import the patch if it's provided: hg imp --no-c 
* If it's just a typo in the default branch, just verify it and
commit: hg commit and hg push
* If not: hg update 3.4, hg commit, hg update default, hg merge 3.4, hg push
* If it's a markup change, build the documentation locally. It'll take
2-3 minutes.

The last two steps would be look tough to follow, it's actually not. I
learned Hg when I started to send patches to CPython and learning a
couple of commands is not that hard IMO.

For GitHub or Bitbucket:

* Review the pull request and merge it via the big green merge button.
* Ask submitter to send another pull request for the 3.4 branch. If I
remember correctly, it's possible to do that from GitHub's UI, but
again opening two pull requests to fix a typo or a markup error isn't
good.
* Or cherrypick it yourself:
  - Update your local clone
  - Cherrypick the commit and push
* We can use Travis CI to build the documentation on GitHub. I don't
think this is a selling point.

I tried to fix a broken URL via the "edit" button in the PyPy repo a
couple of weeks ago. At my first try, Bitbucket opened a pull request
in my fork. It took me 10-15 minutes to open a pull request correctly.
This step would be easier on GitHub. However, I think sending an email
to d...@python.org is the easiest solution.

--Berker
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Please reconsider PEP 479.

[Guido van Rossum]

On Mon, Nov 24, 2014 at 8:14 AM, Isaac Schwabacher 
wrote:

> On 11/23/14, Guido van Rossum  wrote:
>
> > It wouldn't be so bad if we had the occasional generator author writing
> "raise StopIteration" instead of "return" to exit from a generator. (We
> could just add a recommendation against this to the style guide.) But the
> problem is that an unguarded next() call also raises StopIteration.
> Sometimes this is intentional (as in some itertools examples). But
> sometimes an unguarded next() call occurs deep in the bowels of some code
> called by the generator, and this situation is often hard to debug, since
> there is no stack track.
>
> I'll admit I've only skimmed the massive volume of correspondence this PEP
> has generated, but it seems to me that this is the main argument for this
> change. I can only assume that your support for this PEP is informed by
> your experience building Tulip, but isn't this the kind of thing that can
> be accomplished with a warning? Then you can get the same behavior without
> even needing a __future__ import to protect code bases that expect
> StopIteration to propagate (which seems like the more elegant and natural
> thing to do, even if it is more error-prone).
>

Yes, this is my main reason for wanting the change -- but not just for
tulip/asyncio. The issue can be just as baffling for anyone using
unprotected next() calls in the context of a generator. But I'm not sure
where to put the warning. Are you proposing to issue a warning under the
same conditions the PEP says? But then the itertools examples would issue
warnings -- and I bet the advice would typically be "disable warnings"
rather than "fix the code, otherwise it will break hard in Python 3.7".

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Nick Coghlan]

On 25 Nov 2014 02:28, "Brett Cannon"  wrote:
>
>
>
> On Mon Nov 24 2014 at 2:25:30 AM Nick Coghlan  wrote:
>>
>> On 24 November 2014 at 02:55, Brett Cannon  wrote:
>> > On Sun Nov 23 2014 at 6:18:46 AM Nick Coghlan 
wrote:
>> >> Those features are readily accessible without changing the underlying
>> >> version control system (whether self-hosted through Kallithea or
externally
>> >> hosted through BitBucket or RhodeCode). Thus the folks that want to
change
>> >> the version control system need to make the case that doing so will
provide
>> >> additional benefits that *can't* be obtained in a less disruptive way.
>> >
>> > I guess my question is who and what is going to be disrupted if we go
with
>> > Guido's suggestion of switching to GitHub for code hosting?
Contributors
>> > won't be disrupted at all since most people are more familiar with
GitHub
>> > vs. Bitbucket (how many times have we all heard the fact someone has
even
>> > learned Mercurial just to contribute to Python?). Core developers
might be
>> > based on some learned workflow, but I'm willing to bet we all know git
at
>> > this point (and for those of us who still don't like it, myself
included,
>> > there are GUI apps to paper over it or hg-git for those that prefer a
CLI).
>> > Our infrastructure will need to be updated, but how much of it is that
>> > hg-specific short of the command to checkout out the repo? Obviously
>> > Bitbucket is much more minor by simply updating just a URL, but
changing `hg
>> > clone` to `git clone` isn't crazy either. Georg, Antoine, or Benjamin
can
>> > point out if I'm wrong on this, maybe Donald or someone in the
>> > infrastructure committee.
>>
>> Are you volunteering to write a competing PEP for a migration to git and
GitHub?
>
>
> Been there, done that, got the PEP number. I'm just trying to speak from
the perspective of the person who drove us off of svn and on to hg (as well
as drove us off of SourceForge to our own workflow stack). I personally
just want a better workflow. As I said at the beginning, I read your PEPs
and talked to you about them at PyCon and I want something like that to
happen; push button patch acceptance along with CI of patches would go a
long way to making accepting patches easier. But as others have pointed
out, we just don't have the volunteer time to make them happen ATM, so I'm
willing to entertain moving to GitHub or Bitbucket or whatever to improve
our situation.

It may not have been Guido's intention, but his proposal to undercut the
entire Python based version control tooling ecosystem by deeming it
entirely unfit for our purposes has caused me to dramatically re-evaluate
my own priorities.

I consider the status quo to be only mildly annoying, which is why I'd been
willing to defer proposing improvements. If folks are seriously
contemplating proposing a move to GitHub instead, then that changes the
equation significantly.

Regards,
Nick.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Donald Stufft]

> On Nov 24, 2014, at 2:55 PM, Nick Coghlan  wrote:
> 
> 
> On 25 Nov 2014 02:28, "Brett Cannon"  > wrote:
> >
> >
> >
> > On Mon Nov 24 2014 at 2:25:30 AM Nick Coghlan  > > wrote:
> >>
> >> On 24 November 2014 at 02:55, Brett Cannon  >> > wrote:
> >> > On Sun Nov 23 2014 at 6:18:46 AM Nick Coghlan  >> > > wrote:
> >> >> Those features are readily accessible without changing the underlying
> >> >> version control system (whether self-hosted through Kallithea or 
> >> >> externally
> >> >> hosted through BitBucket or RhodeCode). Thus the folks that want to 
> >> >> change
> >> >> the version control system need to make the case that doing so will 
> >> >> provide
> >> >> additional benefits that *can't* be obtained in a less disruptive way.
> >> >
> >> > I guess my question is who and what is going to be disrupted if we go 
> >> > with
> >> > Guido's suggestion of switching to GitHub for code hosting? Contributors
> >> > won't be disrupted at all since most people are more familiar with GitHub
> >> > vs. Bitbucket (how many times have we all heard the fact someone has even
> >> > learned Mercurial just to contribute to Python?). Core developers might 
> >> > be
> >> > based on some learned workflow, but I'm willing to bet we all know git at
> >> > this point (and for those of us who still don't like it, myself included,
> >> > there are GUI apps to paper over it or hg-git for those that prefer a 
> >> > CLI).
> >> > Our infrastructure will need to be updated, but how much of it is that
> >> > hg-specific short of the command to checkout out the repo? Obviously
> >> > Bitbucket is much more minor by simply updating just a URL, but changing 
> >> > `hg
> >> > clone` to `git clone` isn't crazy either. Georg, Antoine, or Benjamin can
> >> > point out if I'm wrong on this, maybe Donald or someone in the
> >> > infrastructure committee.
> >>
> >> Are you volunteering to write a competing PEP for a migration to git and 
> >> GitHub?
> >
> >
> > Been there, done that, got the PEP number. I'm just trying to speak from 
> > the perspective of the person who drove us off of svn and on to hg (as well 
> > as drove us off of SourceForge to our own workflow stack). I personally 
> > just want a better workflow. As I said at the beginning, I read your PEPs 
> > and talked to you about them at PyCon and I want something like that to 
> > happen; push button patch acceptance along with CI of patches would go a 
> > long way to making accepting patches easier. But as others have pointed 
> > out, we just don't have the volunteer time to make them happen ATM, so I'm 
> > willing to entertain moving to GitHub or Bitbucket or whatever to improve 
> > our situation.
> 
> It may not have been Guido's intention, but his proposal to undercut the 
> entire Python based version control tooling ecosystem by deeming it entirely 
> unfit for our purposes has caused me to dramatically re-evaluate my own 
> priorities.
> 
> 

I think this is a misrepresentation of what Guido said. I’m pretty sure he just 
said that Github has “won” over the other sites (which if you define winning in 
terms of who has the mindshare, I think is indisputable) and that he prefers 
git over hg now.
> I consider the status quo to be only mildly annoying, which is why I'd been 
> willing to defer proposing improvements. If folks are seriously contemplating 
> proposing a move to GitHub instead, then that changes the equation 
> significantly.
> 
> Regards,
> Nick.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Nick Coghlan]

On 25 Nov 2014 06:25, "Donald Stufft"  wrote:
>
>
>> On Nov 24, 2014, at 2:55 PM, Nick Coghlan  wrote:
>>
>> It may not have been Guido's intention, but his proposal to undercut the
entire Python based version control tooling ecosystem by deeming it
entirely unfit for our purposes has caused me to dramatically re-evaluate
my own priorities.
>>
>>
>
> I think this is a misrepresentation of what Guido said. I’m pretty sure
he just said that Github has “won” over the other sites (which if you
define winning in terms of who has the mindshare, I think is indisputable)
and that he prefers git over hg now.

That's how a monopoly play works - you invest heavily in rapid growth, aim
to lock in an ecosystem through proprietary APIs, then use that powerful
market position to deliver monopoly rents to the initial investors.

The pattern repeats because "free-as-in-beer" is an extraordinarily
effective marketing tactic.

Cheers,
Nick.

>
>> I consider the status quo to be only mildly annoying, which is why I'd
been willing to defer proposing improvements. If folks are seriously
contemplating proposing a move to GitHub instead, then that changes the
equation significantly.
>>
>> Regards,
>> Nick.
>
>
> ---
> Donald Stufft
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Chris Withers]

On 24/11/2014 02:59, Barry Warsaw wrote:

On Nov 23, 2014, at 08:55 AM, Guido van Rossum wrote:


- Moving from Hg to Git is a fair amount of one-time work


For anyone seriously interested in this, even experimentally, I would highly
suggest looking at Eric Raymond's reposurgeon code.  You can google it or find
it covered in the vast discussions of his conversion of the Emacs repository
from bazaar to git.  I don't know for a fact that it would handle an hg to git
conversion, but it's the most likely candidate for something so complex.
There's a lot of similarity in the history of the Emacs and Python
repositories, having gone through many previous iterations of vcs's - in
Python's case, at least cvs, svn, and hg.


For what it's worth, Mike Bayer successfully migrated SQLAlchemy from 
svn to hg and then to git. He now has an amazing system set up whereby 
commits can be made by contributors through either GitHub or BitBucket, 
I thought he still had Trac rigged up on sqlalchemy.org, but looks like 
the issue tracker has migrated to bitbucket...


I believe his reasons for moving are similar to those I've read in 
Guido's posts.


I believe he also has notes on what he did and how things are set up...

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
   - http://www.simplistix.co.uk
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Donald Stufft]

> On Nov 24, 2014, at 3:48 PM, Nick Coghlan  wrote:
> 
> 
> On 25 Nov 2014 06:25, "Donald Stufft"  > wrote:
> >
> >
> >> On Nov 24, 2014, at 2:55 PM, Nick Coghlan  >> > wrote:
> >>
> >> It may not have been Guido's intention, but his proposal to undercut the 
> >> entire Python based version control tooling ecosystem by deeming it 
> >> entirely unfit for our purposes has caused me to dramatically re-evaluate 
> >> my own priorities.
> >>
> >>
> >
> > I think this is a misrepresentation of what Guido said. I’m pretty sure he 
> > just said that Github has “won” over the other sites (which if you define 
> > winning in terms of who has the mindshare, I think is indisputable) and 
> > that he prefers git over hg now.
> 
> That's how a monopoly play works - you invest heavily in rapid growth, aim to 
> lock in an ecosystem through proprietary APIs, then use that powerful market 
> position to deliver monopoly rents to the initial investors.
> 
> The pattern repeats because "free-as-in-beer" is an extraordinarily effective 
> marketing tactic.
> 
> 

I don’t really think this is a fair comparison either.

“lock in” here doesn’t make any sense to me unless you define lock-in as any 
compelling feature what so ever. Wherever a feature Github added was able to be 
integrated with git itself it did so. PRs for instance could have been done 
using a proprietary CLI client that uploaded patches which couldn’t be easily 
exported. Can you please point out in which ways Github has tried to do “vendor 
lock in” and in addition can you also point out in which ways they don’t apply 
to Bitbucket which you were previously fine with?

As Guido pointed out, the social aspect to a DVCS is an important part of a 
DCVS and Git (and Github) has that. Others (including yourself) have pointed 
out that git vs hg itself is largely isomorphic as far as actual technical 
ability go when you go through and spend the time to figure out what extensions 
you need and configure them. It’s largely the *other* tooling around it and the 
relative sizes of the communities.

If you want to pick a toolchain that isn’t as popular nor as polished or as 
well put together for idealogical reasons than that’s fine, but at least be 
honest about the fact that you’re choosing to prioritize ideology over 
selecting the best toolchain.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Please reconsider PEP 479.

[Isaac Schwabacher]

On 11/24/14, Guido van Rossum  wrote:
> On Mon, Nov 24, 2014 at 8:14 AM, Isaac Schwabacher 
>  wrote:
> 
> > On 11/23/14, Guido van Rossum wrote:
> > 
> > > It wouldn't be so bad if we had the occasional generator author writing 
> > > "raise StopIteration" instead of "return" to exit from a generator. (We 
> > > could just add a recommendation against this to the style guide.) But the 
> > > problem is that an unguarded next() call also raises StopIteration. 
> > > Sometimes this is intentional (as in some itertools examples). But 
> > > sometimes an unguarded next() call occurs deep in the bowels of some code 
> > > called by the generator, and this situation is often hard to debug, since 
> > > there is no stack track.
> > 
> > I'll admit I've only skimmed the massive volume of correspondence this PEP 
> > has generated, but it seems to me that this is the main argument for this 
> > change. I can only assume that your support for this PEP is informed by 
> > your experience building Tulip, but isn't this the kind of thing that can 
> > be accomplished with a warning? Then you can get the same behavior without 
> > even needing a __future__ import to protect code bases that expect 
> > StopIteration to propagate (which seems like the more elegant and natural 
> > thing to do, even if it is more error-prone).
> 
> Yes, this is my main reason for wanting the change -- but not just for 
> tulip/asyncio. The issue can be just as baffling for anyone using unprotected 
> next() calls in the context of a generator. But I'm not sure where to put the 
> warning. Are you proposing to issue a warning under the same conditions the 
> PEP says?

Yes, I'm proposing issuing the warning at the point where the PEP raises, so 
that the PEP's behavior can be obtained with a warning filter (and such a 
filter could be installed by default around the asyncio main loop).

> But then the itertools examples would issue warnings --

That's definitely problematic. They should either be fixed, or have the warning 
silenced with a comment about how the bubbling-up case is expected.

> and I bet the advice would typically be "disable warnings" rather than "fix 
> the code, otherwise it will break hard in Python 3.7".

I don't think it's the language's responsibility to second guess a user who 
decides to explicitly silence such a warning. And if this *is* accomplished 
with a warning, then the user can just continue silencing it in 3.7. In my 
experience, though, python's documentation, StackOverflow presence, blogs, etc. 
have been absolutely stellar in terms of explaining why things are the way they 
are and how one should write pythonic code. I don't doubt the community's 
ability to educate users on this.

I think the biggest stumbling block for this proposal is the fact that the 
current warning machinery doesn't appear to be up to the task of silencing a 
known-harmless warning in one generator without silencing meaningful warnings 
in generators it calls.

ijs
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Please reconsider PEP 479.

[Guido van Rossum]

On Mon, Nov 24, 2014 at 1:32 PM, Isaac Schwabacher 
wrote:

> On 11/24/14, Guido van Rossum  wrote:
> > On Mon, Nov 24, 2014 at 8:14 AM, Isaac Schwabacher <
> ischwabac...@wisc.edu(javascript:main.compose()> wrote:
> >
> > > On 11/23/14, Guido van Rossum wrote:
> > >
> > > > It wouldn't be so bad if we had the occasional generator author
> writing "raise StopIteration" instead of "return" to exit from a generator.
> (We could just add a recommendation against this to the style guide.) But
> the problem is that an unguarded next() call also raises StopIteration.
> Sometimes this is intentional (as in some itertools examples). But
> sometimes an unguarded next() call occurs deep in the bowels of some code
> called by the generator, and this situation is often hard to debug, since
> there is no stack track.
> > >
> > > I'll admit I've only skimmed the massive volume of correspondence this
> PEP has generated, but it seems to me that this is the main argument for
> this change. I can only assume that your support for this PEP is informed
> by your experience building Tulip, but isn't this the kind of thing that
> can be accomplished with a warning? Then you can get the same behavior
> without even needing a __future__ import to protect code bases that expect
> StopIteration to propagate (which seems like the more elegant and natural
> thing to do, even if it is more error-prone).
> >
> > Yes, this is my main reason for wanting the change -- but not just for
> tulip/asyncio. The issue can be just as baffling for anyone using
> unprotected next() calls in the context of a generator. But I'm not sure
> where to put the warning. Are you proposing to issue a warning under the
> same conditions the PEP says?
>
> Yes, I'm proposing issuing the warning at the point where the PEP raises,
> so that the PEP's behavior can be obtained with a warning filter (and such
> a filter could be installed by default around the asyncio main loop).
>
> > But then the itertools examples would issue warnings --
>
> That's definitely problematic. They should either be fixed, or have the
> warning silenced with a comment about how the bubbling-up case is expected.
>

So you agree with the problem that the PEP is trying to solve, you want
people to fix their code in exactly the same way that the PEP is trying to
get them to fix it, you want all new code that exhibits the problem to be
flagged by a warning, and yet you do not support adding a __future__
statement and a a transition plan that replaces the warnings with hard
failures in Python 3.7 (whose release date is going to be at least about
four years in the future)?

That sounds like the most loyal opposition I can wish for! :-)


> > and I bet the advice would typically be "disable warnings" rather than
> "fix the code, otherwise it will break hard in Python 3.7".
>
> I don't think it's the language's responsibility to second guess a user
> who decides to explicitly silence such a warning. And if this *is*
> accomplished with a warning, then the user can just continue silencing it
> in 3.7. In my experience, though, python's documentation, StackOverflow
> presence, blogs, etc. have been absolutely stellar in terms of explaining
> why things are the way they are and how one should write pythonic code. I
> don't doubt the community's ability to educate users on this.
>

Python's philosophy for (runtime) warnings is pretty clear -- a warning
should never be silenced indefinitely. Warnings mean something's wrong with
your code that won't get better by ignoring it, and you should fix it at
some point. Until then you can silence the warning. Silencing warnings is
an important mechanism for users who have no control over the code that
issues the warning, and for devs who have more pressing priorities. But
they should not be used to permanently enable coding in an "alternate
universe" where the language has different features.


> I think the biggest stumbling block for this proposal is the fact that the
> current warning machinery doesn't appear to be up to the task of silencing
> a known-harmless warning in one generator without silencing meaningful
> warnings in generators it calls.
>

You can get pretty darn specific with the warnings silencing machinery: up
to the module and line number. It's intentional that you can't specify a
class/method -- the latter would just encourage devs to silence a specific
warning because they think they know better.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 479: Change StopIteration handling inside generators

[Alexander Belopolsky]

On Wed, Nov 19, 2014 at 3:10 PM, Guido van Rossum  wrote:

> There's a new PEP proposing to change how to treat StopIteration bubbling
> up out of a generator frame (not caused by a return from the frame). The
> proposal is to replace such a StopIteration with a RuntimeError (chained to
> the original StopIteration), so that only *returning* from a generator (or
> falling off the end) causes the iteration to terminate.


I think the PEP should also specify what will happen if the generator's
__next__() method is called again after RuntimeError is handled.  The two
choices are:

1. Raise StopIteration (current behavior for all exceptions).
2. Raise RuntimeError (may be impossible without gi_frame).

I think choice 1 is implied by the PEP.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Please reconsider PEP 479.

[Isaac Schwabacher]

On 11/24/14, Guido van Rossum  wrote:
> On Mon, Nov 24, 2014 at 1:32 PM, Isaac Schwabacher  ischwabac...@wisc.edu> wrote:
> 
> > On 11/24/14, Guido van Rossum wrote:
> > > On Mon, Nov 24, 2014 at 8:14 AM, Isaac Schwabacher 
> > >  > > 't=ischwabac...@wisc.edu>(java_script:main.compose()> wrote:
> > >
> > > > On 11/23/14, Guido van Rossum wrote:
> > > >
> > > > > It wouldn't be so bad if we had the occasional generator author 
> > > > > writing "raise StopIteration" instead of "return" to exit from a 
> > > > > generator. (We could just add a recommendation against this to the 
> > > > > style guide.) But the problem is that an unguarded next() call also 
> > > > > raises StopIteration. Sometimes this is intentional (as in some 
> > > > > itertools examples). But sometimes an unguarded next() call occurs 
> > > > > deep in the bowels of some code called by the generator, and this 
> > > > > situation is often hard to debug, since there is no stack track.
> > > >
> > > > I'll admit I've only skimmed the massive volume of correspondence this 
> > > > PEP has generated, but it seems to me that this is the main argument 
> > > > for this change. I can only assume that your support for this PEP is 
> > > > informed by your experience building Tulip, but isn't this the kind of 
> > > > thing that can be accomplished with a warning? Then you can get the 
> > > > same behavior without even needing a __future__ import to protect code 
> > > > bases that expect StopIteration to propagate (which seems like the more 
> > > > elegant and natural thing to do, even if it is more error-prone).
> > >
> > > Yes, this is my main reason for wanting the change -- but not just for 
> > > tulip/asyncio. The issue can be just as baffling for anyone using 
> > > unprotected next() calls in the context of a generator. But I'm not sure 
> > > where to put the warning. Are you proposing to issue a warning under the 
> > > same conditions the PEP says?
> > 
> > Yes, I'm proposing issuing the warning at the point where the PEP raises, 
> > so that the PEP's behavior can be obtained with a warning filter (and such 
> > a filter could be installed by default around the asyncio main loop).
> > 
> > > But then the itertools examples would issue warnings --
> > 
> > That's definitely problematic. They should either be fixed, or have the 
> > warning silenced with a comment about how the bubbling-up case is expected.
> 
> So you agree with the problem that the PEP is trying to solve, you want 
> people to fix their code in exactly the same way that the PEP is trying to 
> get them to fix it, you want all new code that exhibits the problem to be 
> flagged by a warning, and yet you do not support adding a __future__ 
> statement and a a transition plan that replaces the warnings with hard 
> failures in Python 3.7 (whose release date is going to be at least about four 
> years in the future)?
> 
> That sounds like the most loyal opposition I can wish for! :-)

I agree with you that escaping StopIteration should be easier to notice, but 
with the opposition that allowing StopIteration to escape on purpose is a 
useful technique. But when you put it that way...

> > > and I bet the advice would typically be "disable warnings" rather than 
> > > "fix the code, otherwise it will break hard in Python 3.7".
> > 
> > I don't think it's the language's responsibility to second guess a user who 
> > decides to explicitly silence such a warning. And if this *is* accomplished 
> > with a warning, then the user can just continue silencing it in 3.7. In my 
> > experience, though, python's documentation, StackOverflow presence, blogs, 
> > etc. have been absolutely stellar in terms of explaining why things are the 
> > way they are and how one should write pythonic code. I don't doubt the 
> > community's ability to educate users on this.
> 
> Python's philosophy for (runtime) warnings is pretty clear -- a warning 
> should never be silenced indefinitely. Warnings mean something's wrong with 
> your code that won't get better by ignoring it, and you should fix it at some 
> point. Until then you can silence the warning. Silencing warnings is an 
> important mechanism for users who have no control over the code that issues 
> the warning, and for devs who have more pressing priorities. But they should 
> not be used to permanently enable coding in an "alternate universe" where the 
> language has different features.

I take it all back. ;D Nothing I've run across in the python ecosystem has made 
this point to me. (And google searches for "python warning philosophy" and the 
like don't find it, either.) I was interpreting the warning as indicating that 
there *might* be a problem in user code, so if the user knows why the system 
believes this and knows that the problem is a mirage, then it is reasonable to 
silence the warning indefinitely. In this interpretation it would make sense to 
simply add the warning and rely on users to determine whether their esc

Re: [Python-Dev] Please reconsider PEP 479.

[Guido van Rossum]

On Mon, Nov 24, 2014 at 3:07 PM, Isaac Schwabacher 
wrote:

> On 11/24/14, Guido van Rossum  wrote:
> > On Mon, Nov 24, 2014 at 1:32 PM, Isaac Schwabacher <
> ischwabac...@wisc.edu 
> ischwabac...@wisc.edu> wrote:
> >
> > > On 11/24/14, Guido van Rossum wrote:
> > > > On Mon, Nov 24, 2014 at 8:14 AM, Isaac Schwabacher <
> python.org/~guido(javascript:main.compose('new', 
> 't=ischwabac...@wisc.edu>(java_script:main.compose()>
> wrote:
> > > >
> > > > > On 11/23/14, Guido van Rossum wrote:
> > > > >
> > > > > > It wouldn't be so bad if we had the occasional generator author
> writing "raise StopIteration" instead of "return" to exit from a generator.
> (We could just add a recommendation against this to the style guide.) But
> the problem is that an unguarded next() call also raises StopIteration.
> Sometimes this is intentional (as in some itertools examples). But
> sometimes an unguarded next() call occurs deep in the bowels of some code
> called by the generator, and this situation is often hard to debug, since
> there is no stack track.
> > > > >
> > > > > I'll admit I've only skimmed the massive volume of correspondence
> this PEP has generated, but it seems to me that this is the main argument
> for this change. I can only assume that your support for this PEP is
> informed by your experience building Tulip, but isn't this the kind of
> thing that can be accomplished with a warning? Then you can get the same
> behavior without even needing a __future__ import to protect code bases
> that expect StopIteration to propagate (which seems like the more elegant
> and natural thing to do, even if it is more error-prone).
> > > >
> > > > Yes, this is my main reason for wanting the change -- but not just
> for tulip/asyncio. The issue can be just as baffling for anyone using
> unprotected next() calls in the context of a generator. But I'm not sure
> where to put the warning. Are you proposing to issue a warning under the
> same conditions the PEP says?
> > >
> > > Yes, I'm proposing issuing the warning at the point where the PEP
> raises, so that the PEP's behavior can be obtained with a warning filter
> (and such a filter could be installed by default around the asyncio main
> loop).
> > >
> > > > But then the itertools examples would issue warnings --
> > >
> > > That's definitely problematic. They should either be fixed, or have
> the warning silenced with a comment about how the bubbling-up case is
> expected.
> >
> > So you agree with the problem that the PEP is trying to solve, you want
> people to fix their code in exactly the same way that the PEP is trying to
> get them to fix it, you want all new code that exhibits the problem to be
> flagged by a warning, and yet you do not support adding a __future__
> statement and a a transition plan that replaces the warnings with hard
> failures in Python 3.7 (whose release date is going to be at least about
> four years in the future)?
> >
> > That sounds like the most loyal opposition I can wish for! :-)
>
> I agree with you that escaping StopIteration should be easier to notice,
> but with the opposition that allowing StopIteration to escape on purpose is
> a useful technique. But when you put it that way...
>
> > > > and I bet the advice would typically be "disable warnings" rather
> than "fix the code, otherwise it will break hard in Python 3.7".
> > >
> > > I don't think it's the language's responsibility to second guess a
> user who decides to explicitly silence such a warning. And if this *is*
> accomplished with a warning, then the user can just continue silencing it
> in 3.7. In my experience, though, python's documentation, StackOverflow
> presence, blogs, etc. have been absolutely stellar in terms of explaining
> why things are the way they are and how one should write pythonic code. I
> don't doubt the community's ability to educate users on this.
> >
> > Python's philosophy for (runtime) warnings is pretty clear -- a warning
> should never be silenced indefinitely. Warnings mean something's wrong with
> your code that won't get better by ignoring it, and you should fix it at
> some point. Until then you can silence the warning. Silencing warnings is
> an important mechanism for users who have no control over the code that
> issues the warning, and for devs who have more pressing priorities. But
> they should not be used to permanently enable coding in an "alternate
> universe" where the language has different features.
>
> I take it all back. ;D Nothing I've run across in the python ecosystem has
> made this point to me. (And google searches for "python warning philosophy"
> and the like don't find it, either.) I was interpreting the warning as
> indicating that there *might* be a problem in user code, so if the user
> knows why the system believes this and knows that the problem is a mirage,
> then it is reasonable to silence the warning indefinitely. In this
> interpretation it would make sense to simply add the warning and rely on
> users to d

Re: [Python-Dev] PEP 479: Change StopIteration handling inside generators

[Guido van Rossum]

On Mon, Nov 24, 2014 at 4:21 PM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:

>
> On Wed, Nov 19, 2014 at 3:10 PM, Guido van Rossum 
> wrote:
>
>> There's a new PEP proposing to change how to treat StopIteration bubbling
>> up out of a generator frame (not caused by a return from the frame). The
>> proposal is to replace such a StopIteration with a RuntimeError (chained to
>> the original StopIteration), so that only *returning* from a generator (or
>> falling off the end) causes the iteration to terminate.
>
>
> I think the PEP should also specify what will happen if the generator's
> __next__() method is called again after RuntimeError is handled.  The two
> choices are:
>
> 1. Raise StopIteration (current behavior for all exceptions).
> 2. Raise RuntimeError (may be impossible without gi_frame).
>
> I think choice 1 is implied by the PEP.
>

Good catch. It has to be #1 because the generator object doesn't retain
exception state. I am behind with updating the PEP but I promise I won't
mark it as Accepted without adding this, the transition plan, and a
discussion of some of the objections that were raised.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Ethan Furman]

On 11/24/2014 08:36 AM, Donald Stufft wrote:
> On Nov 24, 2014, at 11:28 AM, Brett Cannon wrote:
>>
>> This might be a little controversial, but the PSF's mission should not 
>> influence a decision of python-dev.

Yet what we do can reinforce, or undermine, the PSF.


>> The only reason we didn't go with Jira for our issue tracker was because of 
>> pressure to not go with a closed-source
>> solution [...]

> This is really what I’m trying to do but I’m apparently not getting my point 
> across very well. I want us to pick the
> best tool for the job regardless of what language it’s written in.

As an open source project it behooves us to support open source solutions, even 
if a "better" closed-source solution exists.

It is sounding to me like GitHub is not, itself, an open solution, even though 
they may support open source.

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Donald Stufft]

> On Nov 24, 2014, at 8:59 PM, Ethan Furman  wrote:
> 
> On 11/24/2014 08:36 AM, Donald Stufft wrote:
>> On Nov 24, 2014, at 11:28 AM, Brett Cannon wrote:
>>> 
>>> This might be a little controversial, but the PSF's mission should not 
>>> influence a decision of python-dev.
> 
> Yet what we do can reinforce, or undermine, the PSF.
> 
> 
>>> The only reason we didn't go with Jira for our issue tracker was because of 
>>> pressure to not go with a closed-source
>>> solution [...]
> 
>> This is really what I’m trying to do but I’m apparently not getting my point 
>> across very well. I want us to pick the
>> best tool for the job regardless of what language it’s written in.
> 
> As an open source project it behooves us to support open source solutions, 
> even if a "better" closed-source solution exists.
> 
> It is sounding to me like GitHub is not, itself, an open solution, even 
> though they may support open source.

I’d agree if the tooling was comparable, but at the end of the day the closed 
source tool is better and more popular. It isn’t Python’s job to fall on the 
sword in the name of some greater ideology while other languages get to pick 
the tooling that best enables them to serve the faith that their users have put 
in them. “Practicality beats Purity” after all.

You might lament the fact that the closed source tool is the better option, but 
the right response to that is to make an OSS alternative that is more, or at 
least as, compelling as the closed source solution and then market that and 
win. 

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Ethan Furman]

On 11/24/2014 06:27 PM, Donald Stufft wrote:
> On Nov 24, 2014, at 8:59 PM, Ethan Furman wrote:
>>
>> It is sounding to me like GitHub is not, itself, an open solution, even 
>> though
>> they may support open source.
> 
> I’d agree if the tooling was comparable, but at the end of the day the closed
> source tool is better and more popular. It isn’t Python’s job to fall on the
> sword in the name of some greater ideology while other languages get to pick
> the tooling that best enables them to serve the faith that their users have 
> put
> in them. “Practicality beats Purity” after all.
> 
> You might lament the fact that the closed source tool is the better option, 
> but
> the right response to that is to make an OSS alternative that is more, or at
> least as, compelling as the closed source solution and then market that and 
> win.

Or, make a list of the must-haves from the (for whatever reason) controversial 
choice, and implement them in our own
infrastructure.

(Yeah, I guess I'm volunteering to help with that effort. ;)

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Donald Stufft]

> On Nov 24, 2014, at 9:37 PM, Ethan Furman  wrote:
> 
> On 11/24/2014 06:27 PM, Donald Stufft wrote:
>> On Nov 24, 2014, at 8:59 PM, Ethan Furman wrote:
>>> 
>>> It is sounding to me like GitHub is not, itself, an open solution, even 
>>> though
>>> they may support open source.
>> 
>> I’d agree if the tooling was comparable, but at the end of the day the closed
>> source tool is better and more popular. It isn’t Python’s job to fall on the
>> sword in the name of some greater ideology while other languages get to pick
>> the tooling that best enables them to serve the faith that their users have 
>> put
>> in them. “Practicality beats Purity” after all.
>> 
>> You might lament the fact that the closed source tool is the better option, 
>> but
>> the right response to that is to make an OSS alternative that is more, or at
>> least as, compelling as the closed source solution and then market that and 
>> win.
> 
> Or, make a list of the must-haves from the (for whatever reason) 
> controversial choice, and implement them in our own
> infrastructure.
> 
> (Yeah, I guess I'm volunteering to help with that effort. ;)

Isn’t that essentially what I said? ;) Unless you were planning to make the 
implementations on our own infrastructure closed source. Sadly it’s not just a 
feature matrix that you need to fill out some check boxes, the closed source 
software in question just flat out *works* better than any of it’s open source 
counter parts. Tacking on some features onto an existing solution does not 
compare.

There’s also the social aspects of it as well which is a big concern too IMO. 
If you want to attract new contributors, not just keep the ones you already 
have sometimes that means going to where the new contributors are instead of 
telling them that they need to come to you.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Please reconsider PEP 479.

[Nick Coghlan]

On 25 November 2014 at 10:47, Guido van Rossum  wrote:
> In my defense, the docs for the warnings module on docs.python.org at start
> like this:
>
> "Warning messages are typically issued in situations where it is useful to
> alert the user of some condition in a program, where that condition
> (normally) doesn’t warrant raising an exception and terminating the program.
> For example, one might want to issue a warning when a program uses an
> obsolete module."
>
> I admit that's only a single example, but it does refer to something that
> will break in the future.

The logging tutorial also recommends limiting the use of
warning.warn() to cases where the code triggering the warning can and
should be changed to avoid the warning:
https://docs.python.org/3/howto/logging.html#when-to-use-logging

Vinay explicitly noted it there to contrast with the fact that
logging.warn() is for cases that are dubious and should potentially be
investigated by the application developer, but there's no specific
code change to be made to avoid the warning.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PCBuild project updates

[Tim Golden]

On 22/11/2014 22:10, Steve Dower wrote:

Just attracting some attention to http://bugs.python.org/issue22919
for those of us who build Python out of the PCBuild folder. More
details/patches there, but the tl;dr is

* Still works with VS 2010 (and now VS 2013 and VS 2015 too) * Build
time should be reduced * Tools\buildbot\*.bat are also updated, so
buildbots shouldn't notice any change

If you're concerned/interested, I'll be watching the tracker for
comments. Ideally I'd like at least a couple of people to test build
with whatever VS version they have, but if nobody can do that then
I'll assume that nobody will notice anything break sooner than me :)



I'm trying to find the time to look, but every time I go there, there's 
a newer review and a later update :) I view this as a good sign.


My VS-fu is minimal but I'll try to pull and build against VS2010 which 
is all I have installed. As an overview point, though, I think it's 
great to have a good spring-cleaning of our Win-based setup, so thanks 
anyway.


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Nick Coghlan]

On 25 November 2014 at 13:18, Donald Stufft  wrote:
>
> There’s also the social aspects of it as well which is a big concern too IMO. 
> If you want to attract new contributors, not just keep the ones you already 
> have sometimes that means going to where the new contributors are instead of 
> telling them that they need to come to you.

Again, the bottleneck at the moment is *reviewing* contributions, not
getting more of them. The two aspects are not unrelated, but my key
concern at this point is to make the patch review and acceptance
process easier, moreso than to increase the rate of incoming patches.

My short term proposal to consider BitBucket as an option for support
repo hosting purposes was mostly driven by my delays in getting the
end-to-end signing PEPs for PyPI updated in a timely fashion - that
would have been much easier if the authors had been able to submit
pull requests, and I just reviewed and accepted them.

The subsequent discussion has made me realise that dissatisfaction
with the current state of the infrastructure amongst core developers
is higher than I previously realised, so I've re-evaluated my own
priorities, and will be spending more time on both PEP 474
(forge.python.org) and PEP 462 (the far more complex proposal to
consider introducing OpenStack style merge gating for CPython).

At present, it looks like significant workflow improvements for the
main CPython repos will require custom tooling - there's very little
out there that will adequately support a long term maintenance branch,
a short term maintenance branch, additional security fix only
branches, and a separate main line of development.

Having our own Kallithea installation would provide additional
implementation options on that front, so I'll be keeping that in mind
as I work to get the proof-of-concept forge instance online.

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com