[python-committers] Re: IMPORTANT: Check the 3.11.0 cherry-picks

[Gregory P. Smith]

On Mon, Oct 24, 2022 at 3:59 AM Pablo Galindo Salgado 
wrote:

> Hi everyone,
>
> I emerged from cherry-picking hell! As mentioned previously, the 3.11.0
> final release will be done from the "branch-v3.11.0" branch
> and will contain a bunch of cherry-picked commits on top of v3.11.0rc2.
> These commits are:
>
> * All documentation commits that **do not touch** any source code (120+
> commits).
> * The following bugfixes:
>
> + 6b82cb8 gh-95027: Fix regrtest stdout encoding on Windows (GH-98492)
> + 970c10aa6d0 gh-97616: list_resize() checks for integer overflow
> (GH-97617)
> + 67f5d24e44c gh-96848: Fix -X int_max_str_digits option parsing (GH-96988)
> + 9e008fe3519 gh-96821: Fix undefined behaviour in `_testcapimodule.c`
> (GH-96915) (GH-96927)
> + bac61bc5b13 gh-95778: Mention sys.set_int_max_str_digits() in error
> message (GH-96874)
> + 9cb7324e8fc [3.11] gh-96587: Raise `SyntaxError` for PEP654 on older
> `feature_version` (GH-96588) (#96591)
> + 84fd4a54a61 [3.11] gh-97897: Prevent os.mkfifo and os.mknod segfaults
> with macOS 13 SDK (GH-97944) (#97969)
> + 1a788914ca6 gh-96865: [Enum] fix Flag to use CONFORM boundary (GH-97528)
> + c95433573ac [3.11] gh-98331: Update bundled pip to 22.3 (GH-98332)
> (gh-98400)
> + fc127628d58 gh-98414: py.exe launcher does not use defaults for
> -V:company/ option (GH-98460)
> + 585c95df957 [3.11] GH-97752: Clear the previous member of newly-created
> generator/coroutine frames (GH-97812)
> + 4e0fda59f1f gh-98360: multiprocessing now spawns children on Windows
> with correct argv[0] in virtual environments (GH-98462)
> + 4c0c1e201a8 [3.11] gh-97514: Don't use Linux abstract sockets for
> multiprocessing (GH-98501) (GH-98502)
> + d0ab10f6f01 [3.11] GH-97002: Prevent _PyInterpreterFrames from backing
> more than one PyFrameObject (GH-98002)
> + 154b3cd7516 GH-96975: Skip incomplete frames in PyEval_GetFrame
> (GH-97018)
>
>
> Please *check these commits* and let me know ASAP if we are missing
> something you would like to include on the 3.11.0 final release.
>
> You have until 15:00 UTC+0 today to let me know, otherwise, your changes
> will need to wait until 3.11.1.
>

Github is claiming this list_resize() commit does not exist on a branch for
me?
 https://github.com/python/cpython/commit/970c10aa6d0

Is that just github being wonky or something else?

I double checked the following commits and they look good and show up on
github as being on branch-v3.11.0:
 https://github.com/python/cpython/commit/67f5d24e44c
 https://github.com/python/cpython/commit/bac61bc5b13
 https://github.com/python/cpython/commit/4c0c1e201a8

I didn't check others, those were the ones I was familiar with.

-gps


> Thanks for your help!
>
> Regards from sunny London,
> Pablo Galindo Salgado
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/SB5PWB32JQHE7QFIULXIZIGUFPKSYEKP/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/YKUFFBNL45IQPPS73AGDR3OOQIGAXHAM/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: [action requested] Python Core Dev Sprint 2022 survey / RSVP

[Gregory P. Smith]

We've got room, I'll send you the info.

On Thu, Sep 29, 2022, 10:45 AM fwierzbi...@gmail.com 
wrote:

> Hi all,
>
> I recently found myself with extra free time that I've been devoting to
> working with Jeff Allen to get a Jython3 proof of concept going. This extra
> free time also means that, if it isn't too much to ask, I have the time to
> "crash" the Python Core Dev Sprint this year. I know I'm very late to the
> party, I can bring my own food and stay away from anything that can't
> handle an extra person. Let me know please :)
>
> -Frank
>
> On Thu, Aug 11, 2022 at 11:24 AM Gregory P. Smith  wrote:
>
>> In-case yesterday's mail got flagged as spam due to being sent from
>> Google Forms directly to the mailing list (which made it show up marked
>> "suspicious" even on my end):
>>
>> I sent out an attendance survey for the CPython Core Dev Sprint this
>> October 3-7, 2022:  https://forms.gle/j5baU9GTQtXpQE578
>>
>> Please be sure to reply if you haven't already.
>>
>> -gps
>> ___
>> python-committers mailing list -- python-committers@python.org
>> To unsubscribe send an email to python-committers-le...@python.org
>> https://mail.python.org/mailman3/lists/python-committers.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-committers@python.org/message/JPNVNWKCT6EAAVACF2FMMCBDNVY6ZY3H/
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/FN2M5FDUMMVYH5IBCKDBNWYCHVEIC76P/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [action requested] Python Core Dev Sprint 2022 survey / RSVP

[Gregory P. Smith]

In-case yesterday's mail got flagged as spam due to being sent from Google
Forms directly to the mailing list (which made it show up marked
"suspicious" even on my end):

I sent out an attendance survey for the CPython Core Dev Sprint this
October 3-7, 2022:  https://forms.gle/j5baU9GTQtXpQE578

Please be sure to reply if you haven't already.

-gps
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/JPNVNWKCT6EAAVACF2FMMCBDNVY6ZY3H/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Consider adding a Tier 3 to tiered platform support

[Gregory P. Smith]

On Fri, Apr 1, 2022 at 12:22 PM Brett Cannon  wrote:

>
> On Thu, Mar 31, 2022 at 4:40 PM Victor Stinner 
> wrote:
>
>> Hi,
>>
>> I don't think that the current PEP 11 draft (*) describes correctly
>> the current status of a bunch of platforms which are not "actively"
>> supported. I like to call these plaforms as "best effort support"
>> platforms. I propose considering adding an explicit "Tier 3" to PEP
>> 11.
>>
>> (*) https://github.com/python/peps/pull/2442/
>>
>> Rust defines its Tier 3 as: "Tier 3 targets are those which the Rust
>> codebase has support for, but which the Rust project does not build or
>> test automatically, so they may or may not work."
>>
>> Tier 3 requirements would be *very weak*:
>>
>> * No buildbot requirement
>> * No assigned core dev needed
>> * Don't revert a change breaking a Tier 3 platform
>> * Don't hold a Python release if a Tier 3 platform is broken
>>
>
>> Currently, the "All other platforms" section is quite clear: code can
>> be removed anytime:
>>
>> "Code changes to platforms not listed in the above tiers may rejected
>> or removed from the code base *without a deprecation process* if they
>> cause a maintenance burden or obstruct general improvements."
>>
>> The only difference between "Tier 3" and "All other platforms" would
>> be that removing a platform from Tier 3 require a process. I'm not
>> sure if a deprecation is needed. But we have to go through a
>> discussion and someone (SC?) has to decide if it's ok to drop it
>> (remove code).
>>
>
> If there's no buildbot making sure the platform works and no core dev
> trying to keep it working, then what's the point of listing the platform in
> the PEP? Otherwise I feel that listing a platform as tier 3 just says,
> "there's some code in `main` for it, but we have no clue if it works and we
> won't necessarily try to make it work." And if that's the case then why do
> we need to keep the code around and the cost of readability of our code
> base?
>
>
>>
>> Removing code from Python means in practice that the support *can*
>> still continue, but outside of the Git upstream repository: in a fork
>> instead.
>>
>> For me the main threat of (adding a platform to) Tier 3 is the risk
>> that we might never ever able to drop support for these platforms. PEP
>> 11 would be used by users as a holy document. Maybe we should be clear
>> that Tier 3 is not a strong warranty of long term support, but is just
>> a weak status. For example, put a time bomb: if no developer was
>> available in the last 12 month to fix regressions, drop the platform
>> for Tier 3.
>>
>
> But without a buildbot how do we know when there are regressions and when
> that regression occurred? I wouldn't even know when those 12 months started
> w/ this proposal.
>
>
>>
>> --
>>
>> I'm thinking at these platforms for Tier 3:
>>
>> * AIX 6.4 and newer (has a buildbot)
>> * Android API 24
>> * FreeBSD
>> * OpenBSD
>> * NetBSD
>> * s390x arch
>> * Solaris (has a buildbot)
>>
>> I would prefer to put FreeBSD and s390x in Tier 3 rather than Tier 2.
>>
>> Users of these platforms and contributors who added support for these
>> platforms are going to be grumpy if we drop such platform without any
>> warning or process.
>>
>> Android support seems to be stale for now. But I would prefer to keep
>> it for now.
>>
>> --
>>
>> Last year, I proposed to drop immediately Solaris support (remove code):
>>
>> https://mail.python.org/archives/list/python-...@python.org/thread/VDD7NMEDFXMOP4S74GEYJUHJRJPK2UR3/
>>
>> I read that Solaris was no longer maintained by Oracle. I was wrong.
>> Moreover, many Python users on Solaris started to complained loudly.
>> Not only Solaris is maintained, but it's also under active
>> development. After this thread, Oracle contributed Solaris patches to
>> Python, and set up a buildbot!
>>
>
> If you're referring to https://buildbot.python.org/all/#/workers/47 then
> it hasn't passed a build in months.
>
>
>>
>> I suggest thinking twice before adding a platform to Tier 3. Adding it
>> is easy. But there will always be at least *one* very grumpy Python
>> user of this platform who will fight to death to keep his old precious
>> unmaintained broken platform, even if no one else in the world has
>> access to the hardware (no longer sold) and no one is able to fix
>> regressions.
>>
>> --
>>
>> For now, I would prefer to *not* add the following platforms to Tier
>> 3. Keep them in the gray area of "unsupported" platforms.
>>
>> * DOS
>> * Cygwin
>> * HP-UX
>> * MinGW
>> * VMS (OpenVMS): https://vmspython.org/
>>
>> Time to time, I merge HP-UX fixes if someone proposes a fix and I have
>> some free cycle to review it. Once, I fixed one Unicode issue specific
>> to HP-UX without having access to HP-UX. It's not the most efficient
>> development method for me: it requires a lot of back and forth
>> exchanges with a developer having access to this platform. I don't
>> want to list HP-UX in Tier 3: I don't have access to HP-UX.
>>
>> --
>>
>> M

[python-committers] Re: Requiring PEPs to add/remove modules in the stdlib (and dropping the concept of "provisional")

[Gregory P. Smith]

On Tue, Mar 22, 2022 at 4:36 PM Barry Warsaw  wrote:

> PEP 2 will have to be “un-superseded”, and presumably the devguide (which
> PEP 2 points to) will also need to be updated.
>

we discussed that a bit.  the dev guide makes sense as a "how to do it"
purpose document, useful for constructing PRs.  The PEP makes sense as a
"here's the policy before merging or spending too much time on it". they'd
link to each other, but they have distinct roles.


>
> I think it’s probably fine to drop the idea of provisional APIs.  Aside
> from the limit benefit of evolution within the stdlib, code still gets
> written against provisional APIs and people still complain when they break
> in non-backward compatible ways, so we might as well avoid the whole thing.
>
> -Barry
>
> > On Mar 22, 2022, at 16:26, Brett Cannon  wrote:
> >
> > I had kicked off a discussion a while back at
> https://discuss.python.org/t/how-do-we-want-to-manage-additions-removals-to-the-stdlib/10681
> about how to manage the stdlib (this has nothing to with what the stdlib is
> and thus what belongs in it). It finally bubbled up in the SC agenda and
> after discussing things we have three proposals:
> >   • Update PEP 2 to say a PEP is necessary to add a module to the
> stdlib
> >   • Update PEP 4 to say that a PEP is necessary to deprecate/remove
> a module
> >   • Mark PEP 411 as obsolete and thus dropping the idea of
> provisional modules
> > The PEP requirements are because the stdlib is important to manage
> appropriately and since it's a shared resource it should be something we
> all discuss. The PEP process seems like a good mechanism for both keeping
> what we bring in under control while also making sure people don't break
> people's code needlessly with removals.
> >
> > The dropping of the concept of provisional modules is from simply having
> not seen any true benefit that could have been had in other ways (e.g.
> typing, asyncio, importlib.metadata). In pretty much all cases the APIs
> could have evolved publicly first and then been brought into the stdlib
> once stable (if at all), so the concept of "provisional" just doesn't seem
> worth keeping around.
> >
> > We wanted to see if there was consensus around any of these ideas, hence
> this email. 🙂
> > ___
> > python-committers mailing list -- python-committers@python.org
> > To unsubscribe send an email to python-committers-le...@python.org
> > https://mail.python.org/mailman3/lists/python-committers.python.org/
> > Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/SKD3XJQF44F2BB6BCCACCPDZDRWTCSWC/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/GQKYSLUAZRS2H2DPU7ONFUOPJNO5BARO/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Requiring PEPs to add/remove modules in the stdlib (and dropping the concept of "provisional")

[Gregory P. Smith]

On Tue, Mar 22, 2022 at 5:02 PM Steven D'Aprano  wrote:

> On Tue, Mar 22, 2022 at 04:26:57PM -0700, Brett Cannon wrote:
>
> >1. Update PEP 2 to say a PEP is necessary to add a module to the
> stdlib
> >2. Update PEP 4 to say that a PEP is necessary to deprecate/remove a
> >module
>
> Does that include modules flagged as private?
>
> E.g. the public interface is weakref but there is also a _weakref module.
>

I for one just had "public" in mind while we were discussing this

 _underscore private things are implementation details so long as they do
something unfortunate and leak out into things like pickle state. (and if
anything does that, it is a bug that should be fixed, but takes deprecation
time to drop old support for - i have no examples of this in mind, it is
hopefully made up)

Maybe we want to keep tighter control over the top level stdlib modules
> (such as _weakref) but I hope that what happens inside a package is
> considered internal to the package, e.g. concurrent.futures._base.
>
> If we are discussing these issues, how about refactoring a single file
> module to a package, with no change to the API? E.g.
>
> # Before
> hovercraft.py
>
> # refactor to
> hovercraft/__init__.py
> hovercraft/_privatestuff.py
>

We've done that in the past without incident that I can recall. logging and
unittest for example. It's still "import hovercraft" and is where you'd
store your eels regardless of module vs package.  I don't think that you
need a PEP for that unless you can identify significant negative
consequences.


>
>
> --
> Steve
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/GNEUZNE5TLPUCSUGTDVNRU5EGJ2QKYXG/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/5E7LIDWJIF6BWT2HAZUP4624U26K4CTB/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Gregory P. Smith]

On Mon, Mar 14, 2022 at 11:43 AM Marc-Andre Lemburg  wrote:

> On 14.03.2022 19:34, Brett Cannon wrote:
> > Greg proposed something like "Code changes to support platforms beyond
> tier1 or
> > tier2 may be rejected, broken, or removed from the CPython codebase
> without
> > notice if they cause a maintenance burden for tier1&2 or obstruct general
> > improvements." and drop the concept of tier 3. Does that work for you?
>
> Almost :-) I don't understand the "without notice". I guess Greg
> meant "without deprecation process". Removal of support code should
> be discussed on a ticket and then listed in PEP 11 and
> mentioned in the NEWS file, as usual.
>

I guess I was trying to convey that we may not even have a way to know that
we're breaking something on a non-tier1/2 platform anyways so "without
notice" was just me trying to set people's expectations.  We don't go out
of our way to _try_ and break things most of the time.  "without a
deprecation process" is also reasonable wording.  Feel free to adopt those
words.

Ideally we try to have discussion somewhere relevant when we _know_ we'd
intentionally be removing support for something (for example of why: See
the debacle that happened when dropping Solaris support was proposed).

-gps


>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, Mar 14 2022)
> >>> Python Projects, Coaching and Support ...https://www.egenix.com/
> >>> Python Product Development ...https://consulting.egenix.com/
> 
>
> ::: We implement business ideas - efficiently in both time and costs :::
>
>eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>Registered at Amtsgericht Duesseldorf: HRB 46611
>https://www.egenix.com/company/contact/
>  https://www.malemburg.com/
>
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/STJAMJ45INJB2KDRMNDK6Y6REHZRAXTY/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/CLOM7G3QY3WBOY6XXBJWHOABEUHWXB4W/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

[Gregory P. Smith]

On Fri, Mar 11, 2022 at 10:45 AM Brett Cannon  wrote:

>
> On Fri, Mar 11, 2022 at 9:16 AM Paul Moore  wrote:
>
>> On Fri, 11 Mar 2022 at 17:09, Marc-Andre Lemburg  wrote:
>> >
>> > On 11.03.2022 17:42, Zachary Ware wrote:
>> > >
>> > > - Only code which either supports a higher-tier platform or is a
>> general improvement may be checked in.
>> >
>> > My understanding of that sentence is: PRs which target platforms
>> > not listed in PEP 11 may not be checked in.
>> >
>> > IMO, it doesn't make sense to prohibit support code in the
>> > code base, if there is community interest in this. By dropping
>> > that line, we wouldn't have a problem and also don't
>> > need to list platforms in a tier 4 section, since it's still
>> > possible to add support in the main code base, without having
>> > a core dev maintain it.
>>
>> I agree, the simplest solution here seems to be just to not include
>> that line. We can still push back on PRs for unsupported platforms if
>> we want, we just won't have a policy that *requires* us to do so.
>>
>> If it turns out that leaving it to core devs' judgement is a problem,
>> we can agree a policy with some concrete examples to inform us.
>>
>
> It's already a guideline we hold, but I'm fine with weakening the language
> to make more of a cautious warning to only merge paltform-specific code if
> you have good reasons to.
>

I wouldn't word it as a prohibition.  Just get rid of the line entirely.

I'd also get rid of Tier 3.  It isn't useful - that tier doesn't *block*
anything so we shouldn't be maintaining a documented list of things that
come and go at that level.  That's pure makework and conveys nothing that
the existence of a buildbot does not already do.

If you want a line to include about code supporting non tier1/2 platforms,
I'd word it as:

"Code changes to support platforms beyond tier1 or tier2 may be rejected,
broken, or removed from the CPython codebase without notice if they cause a
maintenance burden for tier1&2 or obstruct general improvements."

This simplifies the story and better reflects reality.  Things listed in a
tier are meaningful without 3 because they block releases rather than
needing to know that tier 3 is a no-op.

The buildbot concept of "stable" is arbitrary.  It is a configuration tag.
There is no strict authority to gatekeep and curate it.  If a release
manager or steering council said to remove the "stable" tag from a buildbot
they'd likely be listened to. Otherwise it's collectively up to whomever
maintains the bot configs and approves the config PRs.  Stability of a
machine setup for reliability purposes is unrelated to importance.

Ex: I don't tag my raspbian bot as "stable" because it lives at home where
I provide a SLO of nothing.  It has nothing to do with importance.  It is
clearly a more important platform than wasm today.

> .. [ubuntu-20_01]

Call this link ubuntu-20_04 to avoid confusion.  Ubuntu versions are always
YY.04 and YY.10 unless they miss their planned release window [rare].

-gps
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/YPQ7H5HD3X2EY522M75OM6CQQZNLWWOD/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: list of core-devs, triagers, etc.

[Gregory P. Smith]

 > - Subscriptions may expire for lack of activity, but resubscribing is
welcomed.

This does not mean we *need* to expel people due to inactivity.  Lurking is
one method of learning.  Manually, I would not bother to try and remove
inactive subscribers until an actual problem arises.

If we do want to do this, it should be a fully automated process that
happens on a scheduled basis with a scheduled idea of who is auto
unsubscribed.  something like a quarterly process that removes people who
are not on python-committers who have not posted in over 12 months.  or any
similar definition of dates.  well defined automation removes any feeling
of targeting or arbitrary moderator whim.

my 2 cents,
-gps


On Thu, Feb 17, 2022 at 9:48 AM Ethan Furman  wrote:

> Accidentally trimmed footnote with link to list info page, so reproducing
> the page itself here:
>
>  > Summary
>  >
>  > Python Core Development Mentorship
>  >
>  > The Python Core Development Mentorship list is intended to provide a
> welcoming introductory
>  > environment for developers interested in contributing to core Python
> development.
>  >
>  > The list is moderated and private; this means:
>  >
>  > - Only subscribers may post messages without moderator approval.
>  > - Only messages relating to core development are allowed.
>  > - Messages with the primary purpose of promoting commercial offerings
> will not be tolerated. [0]
>  > - Messages containing any type of tracking technology will not be
> tolerated. [1]
>  > - Subscriptions may expire for lack of activity, but resubscribing is
> welcomed.
>  >
>  > Subscribing also means receiving messages sent only to the list, rather
> than relying on being
>  > included in the CC list for replies.
>  >
>  > In addition to this list, written guidelines for contributing can be
> found in the Developer's
>  > Guide for CPython: https://devguide.python.org .
>  >
>  > A major goal of this group is to help new contributors feel more
> confident about participating
>  > in the results-focused public environments of the bug tracker,
> python-dev, and python-ideas.
>  >
>  > The following code of conduct is not meant as a means for punishment,
> action, or censorship for
>  > the mailing list or project. Instead, it is meant to set the tone,
> expectations, and comfort
>  > level for mentors and those wishing to be mentored on the list.
>  >
>  > - We ask everyone to be welcoming, friendly, and patient.
>  > - Flame wars and insults are unacceptable in any fashion, by any party.
>  > - Anything can be asked, and "RTFM" is not an acceptable answer.
>  > - Neither is "it's in the archives, go read them".
>  > - List archives are available only to subscribers, but subscription is
> open to everyone.
>  > - Since the archives are closed cross posting to public mailing lists
> is discouraged.
>  > - Statements made by core developers can be quoted outside of the list.
>  > - Statements made by others can not be quoted outside the list without
> explicit permission. [2]
>  > - We endorse the PSF's Diversity statement.
>  > - All participants are expected to follow the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct/
>  > - The list administrators reserve the right to revoke the subscription
> of members (including mentors) that
>  >   persistently fail to abide by this Code of Conduct.
>  >
>  > [0] This is a grey area: Mentioning a commercial offering by a
> regularly active member as part of a
>  > relevant response to a question is fine; so is a genuine question
> including mention of a commercial product
>  >
>  > [1] Use of tracking is grounds for immediate revocation of list
> membership.
>  >
>  > [2] Anonymised, paraphrased statements or questions are okay; direct
> quotes with or without names are not.
>
>
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/KRJKHEHPGFFOCRJQ66PVXOAAA53EZYAP/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/L5GOWNJZTJ5WO7VPWX27JKPSZ66JAYVZ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: core-dev chat

[Gregory P. Smith]

On Mon, May 17, 2021 at 6:44 PM Kyle Stanley  wrote:

>
> FWIW, I would love to add a core dev Discord server to my long-ish list of
>> Discord servers. It's a chat platform I find convenient (much more so than
>> Zulip and Slack, and slightly more so than IRC), very organised, with good
>> moderation tools (better than Slack and IRC), and widely adopted. If people
>> prefer other platforms I will endeavour to participate, but it won't be as
>> convenient to me as Discord.
>>
>
> Huge +1. I'd love to have a place to hang out and voice chat (or text)
> with others on the core team in real time. I think it would double as a
> great social outlet, and we could keep it very simple to the point where
> its basically just IRC with some extra features. Using existing servers
> like PySlackers or Python Discord aren't ideal options (as much as I love
> Python Discord), just because there's too much noise to filter out if one
> is only interested in the core dev aspect. Whatever we do, I think it needs
> to be just for the core development community with as little noise as
> possible.
>

+1 agreed. Discord wins out in terms of features and **being where people
are already at** in terms of modern IRC with replacement with bonus audio
and video features for use when desired. I rarely bother to hang out on
freenode IRC anymore out of inertia and being yet another window to poll.
discord having a mobile app gives a much better signal and a chance that
I'll stop by.  It is also already where things like circuitpython happen.

None of that changes the fact that many of us won't remain online and
responsive in yet another channel at most times. We're not "on call" for
core dev. But we're probably not online and responsive at low latency in
the existing channels either so this shouldn't come as a shock.

-gps
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/ZAH3QUOQR5DBN3YSRQG4EEYN2VGJ7WIF/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: core-dev chat

[Gregory P. Smith]

We already have https://python.zulipchat.com/ setup.
https://mail.python.org/pipermail/python-dev/2018-April/152826.html

I don't hang around there all the time, but I usually re-open a window
there around pycons and core dev sprints.

-gps


On Thu, May 13, 2021 at 4:53 PM Guido van Rossum  wrote:

> I’ve found Gitter works well. I’d use that, assuming it was only open to
> core devs and invitees.
>
> On Thu, May 13, 2021 at 16:39 Senthil Kumaran  wrote:
>
>> Hello Core Dev,
>>
>> I find a need for a core-dev chat service, wherein I could engage in
>> some quick effervescent conversations.
>>
>> It is like a team chat, that is popular with remote work these days.
>> We even seem to have used Zoom Chat yesterday!
>>
>> * I know #python-dev in IRC exists, but it is mostly a channel for
>> bots to send notifications, and there are plenty.  I am not certain if
>> any core dev is active there. There was a time when this was active.
>> * We tried python discord last year, and were bit overwhelmed with the
>> number of channels and inability to customize
>> * There seems to be Slack called pyslackers too[1]. I am yet to try it.
>>
>> To have a proper team-chat, we need a service (a) as well as (b) team
>> using that.
>>
>> Does anyone else feel the need? Should we explore any? My thoughts and
>> options are
>>
>> a) Resurrect #python-dev - changing notifications to different group.
>> b) Request for core-dev in pyslackers Slack
>> c) Request for core-dev in Discord.
>>
>> Any other ideas are welcome.
>>
>> If you think that chatting is not a good idea, and a mailing list, and
>> discourse(discuss.python.org) are the best option, please share your
>> thoughts as well.
>>
>> If we feel a chat service will be a good idea for core-dev to
>> hangaround, then we can go to stage 2 of choosing the service by votes
>> in discourse (discuss.python.org).
>>
>>
>> Thank you,
>> Senthil
>> ___
>> python-committers mailing list -- python-committers@python.org
>> To unsubscribe send an email to python-committers-le...@python.org
>> https://mail.python.org/mailman3/lists/python-committers.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-committers@python.org/message/BVPITIYRECSGCX2JUTMT7F7CCCYQSK4K/
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
> --
> --Guido (mobile)
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/EOYAWR2YDJYPGJCMSYHS7OZYM3MTFWJ5/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/JEUATFULRMNANC3AI4OF5GRTK4RVDYH5/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Publish better than md5sums of Python builds?

[Gregory P. Smith]

On Tue, Mar 16, 2021 at 9:42 AM Christian Heimes 
wrote:

> On 16/03/2021 16.54, Julien Palard wrote:
> > Le 2021-03-16 à 15:52, Christian Heimes a écrit :
> >> could you please explain your use case? Which problem are you trying to
> >> solve? How would a sha256 checksum help you solve that problem?
> >
> > No, I'm just forwarding the surprise of a user seen on a random social
> > network (I'm monitoring the python hashtag on mastodon those days).
>
> The MD5 fingerprint is really just a checksum to detect download issues.
> Any checksum would do the trick, even CRC-32. We could (and should)
> replace the MD5 fingerprint with SHA-256 or SHA-512 [1].
>
> In our case SHA-256 checksums don't provide any real benefit over MD5.
>

The benefit of listing the sha256 for files is that it prevents this
question coming up again and again because md5 is old and rightfully on the
"never use" list for many people. Even if there are situations where it is
fine as an effective improvement over a CRC.


> Security and data integrity is provided by TLS / HTTPS and optionally by
> GPG signatures. The Python source code and checksums are provided by the
> same server. If an attacker is able to modify the tar ball, then it's
> likely they can replace the checksum information, too.
>

People do look at https://python.org/ to get the official checksums of the
downloads at a much different time than the tarball they have lying around
was downloaded.  Hosting them serves as an easy way to check the integrity
of what they already got at some previous time.

Lets not let perfect be the enemy of the good here.

What do other things hosting downloads do?  I see some that list only
sha256.  I see others that list both.  I don't really care which we do so
long as we include something standard not red-flagged as broken due to
collisions.

-gps
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/TINZ4XETYKG3DLZENBZY22X7F4QVUYL7/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Is Tests / Ubuntu broken at the moment?

[Gregory P. Smith]

For lack of better things to do with that...
https://bugs.python.org/issue43382 filed to track it.

On Tue, Mar 2, 2021 at 7:30 PM Gregory P. Smith  wrote:

>
> On Tue, Mar 2, 2021 at 6:44 PM Senthil Kumaran  wrote:
>
>> Hello Python Developers,
>>
>> I notice TLS tests failing in the ssl test suite in master, 3.9 and
>> 3.8 branches.
>>
>> https://github.com/python/cpython/runs/2018191733
>>
>> Is it to do with infrastructure, certificate? I am unable to determine
>> it exactly.
>> The failure is observed upon merge to master. or with 3.8, 3.9
>> backports of any PR.
>>
>
> It's not just you.  This is holding PRs up.  It started within the last
> ~18 hours?
>
> -gps
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/FC7A6FO7YMPGJ7C4Z4NUQQUZ5EOS62IR/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Is Tests / Ubuntu broken at the moment?

[Gregory P. Smith]

On Tue, Mar 2, 2021 at 6:44 PM Senthil Kumaran  wrote:

> Hello Python Developers,
>
> I notice TLS tests failing in the ssl test suite in master, 3.9 and
> 3.8 branches.
>
> https://github.com/python/cpython/runs/2018191733
>
> Is it to do with infrastructure, certificate? I am unable to determine
> it exactly.
> The failure is observed upon merge to master. or with 3.8, 3.9
> backports of any PR.
>

It's not just you.  This is holding PRs up.  It started within the last ~18
hours?

-gps
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/JK6BMWOONSQJTSBBR7UNGPL2P3JSI53O/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Travis CI is no longer mandatory on Python pull requests

[Gregory P. Smith]

On Fri, Oct 16, 2020 at 1:42 AM Victor Stinner  wrote:

> Hi,
>
> Python has no mandatory Linux CI job on pull requests anymore. Right
> now Windows (x64) remains the only mandatory job. Please be careful to
> manually check other CI before merging a PR.
>
> --
>
> We had to deal with at least 3 different issues on the Travis CI over
> the last 6 months. The latest one (3rd issue) is on the Travis CI side
> and is known for months. Sometimes, a Travis CI build completes but
> the GitHub pull request is never updated. Since Travis CI was
> mandatory, it was never possible to merge some pull requests. I also
> noticed a 4th bug, sometimes a PR gets *two* Travis CI jobs on a PR
> for the same Travis CI build, only one is updated, and so again, the
> PR cannot be merged.
>
> For all these reasons, Travis CI was made optional.
>
> I would be nice to have a mandatory Linux job: "Tests / Ubuntu
> (pull_request)" is a good candidate. But I didn't check if it's
> reliable or not.
>

We should simply mark the github actions "Tests / Ubuntu" CI as required.

If we wind up not liking the behavior we can go back on it while we work
something else out.  But it seems dangerous to not have any blocking Linux
CI.  Linux is our most important platform.  With our dev sprint next week
we'll discover if it gets in our way more often than helps rather quickly.

I cannot rightfully apply an automerge label to a code PR so long as we
lack Linux CI to block a merge.

-gps


>
> See https://github.com/python/core-workflow/issues/377 for the discussion.
>
> Note: if someone manages to fix all Travis CI issues, we can
> reconsider making it mandatory again. But it seems like most people
> who tried (included me) are tired or bored by Travis CI.
>
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/JR7HIQHVECHPKH2LE46EACN73KCBLVKE/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/7YTWVS5OXH3NJQBSG55QBSXOMD6RECFG/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: workflow enhancement: a `mark bug as fixed` PR tag [feature request]

[Gregory P. Smith]

On Sun, Oct 11, 2020 at 4:23 PM Berker Peksağ 
wrote:

> On Sun, Oct 11, 2020 at 10:14 PM Gregory P. Smith  wrote:
> >
> > We've got the automerge tag on GH, it+bot make it awesome. There's one
> more thing I'd like to see that could help with bug hygiene: A tag to close
> the associated bug as "fixed" after the merge happens.
>
> You can already do that by adding "(Fixes|Closes) bpo-NNN" to the
> commit message.
>

Oh cool!  where do I put that so that the message automerge generates sees
it?


> --Berker
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/TQEHXONBONVNKEP3EXT637VNTNMQYCW6/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/AJMEMKBLQEYGOYTFNM4XWEQFFTWPTLNR/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: workflow enhancement: a `mark bug as fixed` PR tag [feature request]

[Gregory P. Smith]

On Sun, Oct 11, 2020 at 2:58 PM Victor Stinner  wrote:

> GitHub workflow is nice when a single commit is enough to close an
> issue. But what if a bug should be fixed in multiple branches? Is
> there a way in GitHub to require one commit per branch to close an
> issue?
>

I wasn't worried about automating that case... But it is something we do
reasonably often for bug fixes (merge the PR to main plus PRs to backport
to the past two releases) so it'd be a natural next step. It may be more
difficult to automate and express as it becomes a logical "x and y and z ->
close/fixed" concept.

If you predicate this automation on having switched to github issues, Those
work differently than bpo. We could choose to always "close" after an issue
is fixed in the first branch (usually main; though we occasionally have
issues that are release-only and don't impact main) and use tags on issues
to determine when they still need backports to past releases. The Issue's
"open for backport to 3.9" tag being removed once the fixes land in the
relevant release branch.

That gets complicated, I'd leave that up to whomever designs and implements
our GH Issues workflow (PEP-581 and 588 or otherwise).

-gps


>
> Victor
>
> Le dim. 11 oct. 2020 à 21:16, Guido van Rossum  a écrit
> :
> >
> > Once issues move to GitHub we’ll have this with no additional effort.
> >
> > On Sun, Oct 11, 2020 at 12:14 Gregory P. Smith  wrote:
> >>
> >> We've got the automerge tag on GH, it+bot make it awesome. There's one
> more thing I'd like to see that could help with bug hygiene: A tag to close
> the associated bug as "fixed" after the merge happens.
> >>
> >> This doesn't have to be tied to automerge; in practice you'd find them
> used in unison somewhat often. More readily on features done on the main
> branch rather than bug fixes needing backports to multiple releases.
> >>
> >> We've had such a system at work for so long I don't even remember when
> it was added, but it has been a great time saver. Less more bugs laying
> around fixed but not marked as such.  Less need for triagers to manually
> ask someone who has the permissions to change the bug state. Less
> unintentionally still open bugs in the way distracting people.  Good all
> around.
> >>
> >> It isn't the primary way to close issues, but it helps in situations
> where it makes sense.  I'd assume the same set of people allowed to add
> automerge should be allowed to add this label.
> >>
> >> -gps
> >> ___
> >> python-committers mailing list -- python-committers@python.org
> >> To unsubscribe send an email to python-committers-le...@python.org
> >> https://mail.python.org/mailman3/lists/python-committers.python.org/
> >> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/RTIPINYIWF7IDEEJOVFTMGZPJ2SMYQC3/
> >> Code of Conduct: https://www.python.org/psf/codeofconduct/
> >
> > --
> > --Guido (mobile)
> > ___
> > python-committers mailing list -- python-committers@python.org
> > To unsubscribe send an email to python-committers-le...@python.org
> > https://mail.python.org/mailman3/lists/python-committers.python.org/
> > Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/A6HPANBCT3RHXLBXMQMXCSMLVEQCRF4A/
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
>
> --
> Night gathers, and now my watch begins. It shall not end until my death.
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/OF5HH2VY7TMQH6VPD2ZL5X7HS7PSZTFZ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] workflow enhancement: a `mark bug as fixed` PR tag [feature request]

[Gregory P. Smith]

We've got the automerge tag on GH, it+bot make it awesome. There's one more
thing I'd like to see that could help with bug hygiene: A tag to close the
associated bug as "fixed" after the merge happens.

This doesn't have to be tied to automerge; in practice you'd find them used
in unison somewhat often. More readily on features done on the main branch
rather than bug fixes needing backports to multiple releases.

We've had such a system at work for so long I don't even remember when it
was added, but it has been a great time saver. Less more bugs laying
around fixed but not marked as such.  Less need for triagers to manually
ask someone who has the permissions to change the bug state. Less
unintentionally still open bugs in the way distracting people.  Good all
around.

It isn't the primary way to close issues, but it helps in situations where
it makes sense.  I'd assume the same set of people allowed to add automerge
should be allowed to add this label.

-gps
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/RTIPINYIWF7IDEEJOVFTMGZPJ2SMYQC3/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Language Summit

[Gregory P. Smith]

On Wed, Apr 15, 2020 at 6:53 AM Brett Cannon  wrote:

> joannah nanjekye wrote:
> > Hey all,
> > Unfortunately this year am too busy and cant even attend the language
> > summit mostly.
>
> :( Sorry to hear that.
>
> > However if I knew the schedule, I could sign up for a session or two
> online.
>
> Schedule can be found at https://us.pycon.org/2020/events/languagesummit/.
>
> > Are we going to have recordings of the sessions this year given its a
> zoom?
>
> I personally don't know, but my guess is no for privacy reasons. But Jesse
> will be attending to write up a blog post about what occurs.
>
> -Brett
>

FWIW, I found it surprising to learn that there even was an online language
summit happening (yesterday).  I hadn't heard about that being planned at
all.

Just because I said "no" to attending the physical one sometime in ~January
doesn't mean I would've had the same response to joining an online one.

But I decided to dismiss this as "whatever" rather than a diss.  I realize
coordinating these things takes work and limiting attendance only to those
who signed up for the physical one was probably easiest to transition the
existing plans to.

I am reliant on summaries and anyone attending posting details.  Everyone
please share your slides if you have any that are meaningful without a talk
to go with them. At least to this committers list or discourse forum.  I
expect I feel just like all of our non-travel-enabled colleagues who feel
left out on a recurring basis.  =)

Happy summiting!
-gps



>
> > A chance to catch up later.
> > Best,
> > Joannah Nanjekye
> > "You think you know when you learn, are more sure when you can write,
> even
> > more when you can teach, but certain when you can program." Alan J.
> Perlis
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/TQ67ZFA6FCQNXZMRZDY27PYYDMQJRD3Q/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/WYV6ONZKMCYWKTXSSD4Q2VYYAPWVIQPP/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Welcome Dong-hee Na to the team!

[Gregory P. Smith]

On Wed, Apr 8, 2020 at 8:32 PM Dong-hee Na  wrote:

>
> I still don't know all the parts of Python interpreter/compiler.


Never fear.  None of us do either!  =)

welcome!
-gps
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/36XL6Q5UZ24GGINDGZJVSALLGYEALUY3/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Policy around compile-time flags in bugfix releases

[Gregory P. Smith]

FWIW that is a configure flag, not a flag to the compiler, so I see no
problem with this.  The default build has not changed, it just exposes
another way to build the interpreter.  We've done this in the past with
things like --enable-optimizations and such flags.

In this case it appears to enable "new" code... though from the looks of
the issues around this one, perhaps that is really old code just being
readded and made available via a flag?  That isn't clear to me at a quick
glance on the issues.  Just that it used to use TLS, was changed to
ContextVar, and this flag allows it to keep using TLS.

-gps

On Sun, Mar 1, 2020 at 2:41 AM Antoine Pitrou  wrote:

>
> I don't know.  However, it seems possible given the symptoms of the
> original issue (see ASAN-produced stack trace) that there is a bug when
> using context vars with foreign threads (in this case, C++-created):
> https://bugs.python.org/issue39776
>
> Regards
>
> Antoine.
>
>
> Le 01/03/2020 à 11:30, Łukasz Langa a écrit :
> > Hey there,
> > the release managers noticed Stefan adding a new compile flag and
> > backporting it to (soon to be) 3.7.7 and (eventually to be) 3.8.3.
> >
> > Context: https://bugs.python.org/issue39794
> >
> > Should this go in? It does look like a new feature to us.
> >
> > - Ł and Ned
> >
> > ___
> > python-committers mailing list -- python-committers@python.org
> > To unsubscribe send an email to python-committers-le...@python.org
> > https://mail.python.org/mailman3/lists/python-committers.python.org/
> > Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/5XUQVY4IUPMFZKQP4GPTU2UMJTOLNBQC/
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
> >
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/TFHTQ2TWLKCRENNYAFYY24C4ATJ365YW/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/PZ5NOOKFNQJHCKWQAW4JPR4MLEBTPACD/
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Promote Mark Sapiro and Abhilash Raj as core developers

[Gregory P. Smith]

On Mon, May 13, 2019 at 4:11 PM Barry Warsaw  wrote:

> On May 13, 2019, at 01:14, Victor Stinner  wrote:
>
> > I'm no longer sure myself that I can define them. I prefer to repeat
> > what others say :-) Basically, a core developers is someone who
> > produces commits :-) That's one definition.
>
> But, IMHO not a correct one.  The full quote from PEP 13:
>
> ——snip snip——
> Python core team members demonstrate:
>
> • a good grasp of the philosophy of the Python Project
> • a solid track record of being constructive and helpful
> • significant contributions to the project's goals, in any form
> • willingness to dedicate some time to improving Python
>
> As the project matures, contributions go beyond code. Here's an incomplete
> list of areas where contributions may be considered for joining the core
> team, in no particular order:
>
> • Working on community management and outreach
> • Providing support on the mailing lists and on IRC
> • Triaging tickets
> • Writing patches (code, docs, or tests)
> • Reviewing patches (code, docs, or tests)
> • Participating in design decisions
> • Providing expertise in a particular domain (security, i18n, etc.)
> • Managing the continuous integration infrastructure
> • Managing the servers (website, tracker, documentation, etc.)
> • Maintaining related projects (alternative interpreters, core
> infrastructure like packaging, etc.)
> • Creating visual designs
>
> Core team membership acknowledges sustained and valuable efforts that
> align well with the philosophy and the goals of the Python project.
> ——snip snip——
>
> I’m quite convinced that both Mark and Abhilash meet these requirements.
> And they are almost by definition the experts in the email package.  You
> can certainly see the nature of their work in the Mailman repos, and I
> would be willing to mentor them through the first few commits to the
> CPython repo, though I think it will be mostly perfunctory.
>
> > Having a sustainable Mailman project is great. But how does that
> > relate to Python itself? Are you talking about the email module? Do
> > Mark Sapiro and Abhilash Raj plan to maintain the email module?
>
> Yes, that is the intent.
>
> > In the meanwhile, they don't have to be core devs to help to maintain
> > the email module, no?
>
> Do we have any core developers who want to maintain it?  Not me :) and
> apparently not RDM.
>

I think these two make sense as email module maintainers from a
demonstrated domain expertise point of view.

But you'll probably have an easier time convincing others who want to see
some PRs first if you just go ahead and have them do some work on the email
module in the form of PRs to start with.  ie: Don't let being dubbed core
developers or not yet block you from starting to mentor them on initial
email module maintenance.

-gps


> -Barry
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Merge with spurious CI failures?

[Gregory P. Smith]

fwiw a future way to avoid this mess is in
https://bugs.python.org/issue36855: have the tests support multiple
certificates so we can stage the new ones into our repo before updating the
server.

-gps

On Wed, May 8, 2019 at 11:15 AM Gregory P. Smith  wrote:

> If this cert change is impacting CI checks for everyone's PRs, I suspect
> all PRs will need to merge this change into their branch before they can
> pass CI.
>
> Having CI depend on external network resources does not seem like a good
> idea.
>
> -gps
>
> On Wed, May 8, 2019 at 11:04 AM Antoine Pitrou  wrote:
>
>>
>> Ah, there's already a PR at
>> https://github.com/python/cpython/pull/13192, thanks to Gregory.
>>
>> Regards
>>
>> Antoine.
>>
>>
>> Le 08/05/2019 à 17:58, Antoine Pitrou a écrit :
>> >
>> > Ok, apparently the SSL cert on self-signed.pythontest.net was changed
>> > but it wasn't updated in our source tree, hence the failure.
>> >
>> > Regards
>> >
>> > Antoine.
>> >
>> >
>> > Le 08/05/2019 à 17:49, Mariatta a écrit :
>> >> If you can't merge from GitHub UI then you won't be able to do it from
>> >> GitHub command line (it respects the same branch protection policy)
>> >>
>> >> I don't think we should merge if tests are still failing. Perhaps the
>> >> test should be adjusted to handle this spurious errors? Can it be
>> marked
>> >> as "allowed failure" or something like that?
>> >>
>> >>
>> >> On Wed, May 8, 2019, 8:32 AM Antoine Pitrou > >> <mailto:anto...@python.org>> wrote:
>> >>
>> >>
>> >> Hello,
>> >>
>> >> There are spurious CI failures (SSL certificate issue in
>> test_httplib).
>> >> Therefore the "Squash and merge" button is greyed out.
>> >>
>> >> How should I merge? Using the command-line instructions from
>> Github?
>> >>
>> >> Regards
>> >>
>> >> Antoine.
>> >> ___
>> >> python-committers mailing list
>> >> python-committers@python.org <mailto:python-committers@python.org>
>> >> https://mail.python.org/mailman/listinfo/python-committers
>> >> Code of Conduct: https://www.python.org/psf/codeofconduct/
>> >>
>> > ___
>> > python-committers mailing list
>> > python-committers@python.org
>> > https://mail.python.org/mailman/listinfo/python-committers
>> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>> >
>> ___
>> python-committers mailing list
>> python-committers@python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] miss-islington backport pipeline is stalled?

[Gregory P. Smith]

Yesterday it failed to produce a backport or tell me that it couldn't
(after the "i'm now working on ..." message was left on the master PR).  I
waited a couple hours just in case and ran cherry_picker myself instead.
Same thing today apparently on
https://github.com/python/cpython/pull/13192 assuming
the usual backport latency is no more than a minute or two.

-gps
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Merge with spurious CI failures?

[Gregory P. Smith]

If this cert change is impacting CI checks for everyone's PRs, I suspect
all PRs will need to merge this change into their branch before they can
pass CI.

Having CI depend on external network resources does not seem like a good
idea.

-gps

On Wed, May 8, 2019 at 11:04 AM Antoine Pitrou  wrote:

>
> Ah, there's already a PR at
> https://github.com/python/cpython/pull/13192, thanks to Gregory.
>
> Regards
>
> Antoine.
>
>
> Le 08/05/2019 à 17:58, Antoine Pitrou a écrit :
> >
> > Ok, apparently the SSL cert on self-signed.pythontest.net was changed
> > but it wasn't updated in our source tree, hence the failure.
> >
> > Regards
> >
> > Antoine.
> >
> >
> > Le 08/05/2019 à 17:49, Mariatta a écrit :
> >> If you can't merge from GitHub UI then you won't be able to do it from
> >> GitHub command line (it respects the same branch protection policy)
> >>
> >> I don't think we should merge if tests are still failing. Perhaps the
> >> test should be adjusted to handle this spurious errors? Can it be marked
> >> as "allowed failure" or something like that?
> >>
> >>
> >> On Wed, May 8, 2019, 8:32 AM Antoine Pitrou  >> > wrote:
> >>
> >>
> >> Hello,
> >>
> >> There are spurious CI failures (SSL certificate issue in
> test_httplib).
> >> Therefore the "Squash and merge" button is greyed out.
> >>
> >> How should I merge? Using the command-line instructions from Github?
> >>
> >> Regards
> >>
> >> Antoine.
> >> ___
> >> python-committers mailing list
> >> python-committers@python.org 
> >> https://mail.python.org/mailman/listinfo/python-committers
> >> Code of Conduct: https://www.python.org/psf/codeofconduct/
> >>
> > ___
> > python-committers mailing list
> > python-committers@python.org
> > https://mail.python.org/mailman/listinfo/python-committers
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
> >
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Merge with spurious CI failures?

[Gregory P. Smith]

Our pythontestdotnet repo is different than the cpython repo and the
certificate gets pushed to the server after being committed by hand so it's
a synchronization problem,.

https://github.com/python/cpython/pull/13192 should clear it up.  It's
awaiting the slow CI queuing gods.  It is marked automerge, so if a core
dev could go do a github review and Approve it, it'll go in immediately
after Travis and AppVeyor come back green.

-gps

On Wed, May 8, 2019 at 10:58 AM Antoine Pitrou  wrote:

>
> Ok, apparently the SSL cert on self-signed.pythontest.net was changed
> but it wasn't updated in our source tree, hence the failure.
>
> Regards
>
> Antoine.
>
>
> Le 08/05/2019 à 17:49, Mariatta a écrit :
> > If you can't merge from GitHub UI then you won't be able to do it from
> > GitHub command line (it respects the same branch protection policy)
> >
> > I don't think we should merge if tests are still failing. Perhaps the
> > test should be adjusted to handle this spurious errors? Can it be marked
> > as "allowed failure" or something like that?
> >
> >
> > On Wed, May 8, 2019, 8:32 AM Antoine Pitrou  > > wrote:
> >
> >
> > Hello,
> >
> > There are spurious CI failures (SSL certificate issue in
> test_httplib).
> > Therefore the "Squash and merge" button is greyed out.
> >
> > How should I merge? Using the command-line instructions from Github?
> >
> > Regards
> >
> > Antoine.
> > ___
> > python-committers mailing list
> > python-committers@python.org 
> > https://mail.python.org/mailman/listinfo/python-committers
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
> >
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Can we choose between mailing list and discuss.python.org?

[Gregory P. Smith]

On Wed, Feb 13, 2019 at 12:50 PM Antoine Pitrou  wrote:

>
> Le 13/02/2019 à 21:31, Gregory P. Smith a écrit :
> >
> > I know I can browse easily through a 161-message mailing-list or
> > newsgroup thread using a traditional threaded view, read what I want,
> > come back later to read the rest, etc.  But Discourse's linear
> > presentation pretty much kills that ability.  It doesn't even allow
> > *seeing* the structure of the discussion.
> >
> > Neither does my email client.  It never will, nor can we require mailing
> > list participants to use any specific type of email client.
>
> Apparently you're saying that just because you can't/don't want to use a
> more appropriate tool, other people shouldn't be able too.  That sounds
> ridiculous to me.  Use an inferior tool if you want, but don't force
> other people to.
>

I also use vi (vim, not nvi, i'm not *that* level of cool). ;)

-gps
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Can we choose between mailing list and discuss.python.org?

[Gregory P. Smith]

On Tue, Feb 12, 2019 at 1:59 PM Antoine Pitrou  wrote:

>
> Le 11/02/2019 à 20:00, Barry Warsaw a écrit :
> > On Feb 11, 2019, at 09:48, Victor Stinner  wrote:
> >>
> >> tl; dr How can we decide if we should stop using mailing list or if we
> >> should stop using discuss.python.org?
> >
> > Point of order: I think we need a PEP for this decision.  Such a PEP
> would organize and consolidate the arguments both pro and con of the three
> choices.  It should also cover whether the current Discourse experiment
> translates to larger mailing lists like python-dev, -ideas, and -list (for
> which I personally have uncertainty about).
>
> Same uncertainty here.  I don't think Discourse works well for long
> threads.
>
> Here is a 161-message Discourse thread (at the time of this writing):
> https://discuss.python.org/t/pep-517-backend-bootstrapping/789
>
> I know I can browse easily through a 161-message mailing-list or
> newsgroup thread using a traditional threaded view, read what I want,
> come back later to read the rest, etc.  But Discourse's linear
> presentation pretty much kills that ability.  It doesn't even allow
> *seeing* the structure of the discussion.
>

Neither does my email client.  It never will, nor can we require mailing
list participants to use any specific type of email client.

If we want to enforce an *interface* on people, IMNSHO that is what
something like Discourse is for.  It levels the playing field and provides
modern features way beyond 1900s style email listserv communication while
still allowing interaction via email.

To wit, I also agree with the flat-by-design link posted further down
thread.  Scrollwheel skimming further it looks like what I've said
reinforces points already made by Paul and others.

I don't personally find that _anything_ works well for long threads.  I'm
not convinced that problem is solvable for more than a minority fraction of
participants.  So lets not try ourselves, but lets not reject change
because it doesn't solve that problem.  Look at the existing problems it
_does_ solve and seek to address and understand new problems it creates.
That'd all be part of a Discourse related PEP.

Remember, we could still be using cvs.  Lets not be that project.

-gps
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!

[Gregory P. Smith]

Ned - and any release manager in this situation in the future - has a
default valid answer to this request: No.

If we're ever going to do an "EL" or "LTS" Python, that should be decided
and agreed upon *long before the end of its existing planned maintenance
cycle* instead of right as it is ending.  Ideally before the first x.y.0
with agreement of the release manager.  Though it'd likely be fine to have
that conversation about 3.7 as it is still young, the RM gets final say
into if or how that would work.

I know that I won't be bothering with 3.6 backport/review work myself
anymore outside of special circumstances.

-gps


On Wed, Dec 19, 2018 at 9:46 AM Brett Cannon  wrote:

> [Dropping python-dev so we don't end up swamping the python-committers
> admins -- i.e. me :) -- with posts held for moderation]
>
> On Wed, 19 Dec 2018 at 06:01, Victor Stinner  wrote:
>
>> Hi,
>>
>> I am working in the Red Hat "Python-maint" team which is maintaining
>> Python 3.6 as the main Python interpreter in RHEL 8, which will likely
>> be supported for at least 10 years. And we have been supporting Python
>> 2.7 in RHEL 7. So obviously, being able to benefit of the upstream
>> effort and infra to have a Python 3.6 Long Time Support (LTS) would
>> help us :-)
>>
>> The question is more who else would benefit from that and is it worth
>> it? I don't want Python upstream to pay the price of the maintenance
>> burden of RHEL 8 lifecycle.
>
>
> And for me that extends to Ubuntu LTS releases as well.
>
>
>> For example, supporting a version means to
>> have a working CI (Travis CI, AppVeyor, VSTS, buildbots). I would
>> suggest to only support a very few platforms for the LTS. I propose to
>> restrict to Linux. It doesn't mean to break other platforms on
>> purpose, just to restrict CI to the bare minimum. If Microsoft is
>> interested, we can also support Windows as well.
>>
>
> But that doesn't help someone like me who isn't working on Linux, so it's
> still work to support just Linux compared to Windows or macOS. Plus
> supporting just Linux in CI and such is still not free either.
>
>
>>
>> RHEL 7 is based on Python 2.7.5 which has been released in 2013 (5
>> years ago) and there are 150 patches on top of it: it means that
>> around 30 patches are added per year. I would suggest to have a very
>> strict policy on which changes are backported into 3.6: only the most
>> critical bugfixes, but all security fixes obviously.
>>
>> If we extend Python 3.6 lifetime, do we need a new release manager
>> when the initial lifetime (usually 5 years) ends? Benjamin Peterson
>> accepted to be the Python 2.7 release manager for 10 years (instead of
>> 5 years initially). We could ask Ned Deily about Python 3.6 LTS :-) We
>> would need a group of people reviewing individual 3.6 pull requests to
>> decide to pick them or not. I would volunteer to review these PRs and
>> merge them.
>>
>> The idea isn't new, Nick Coghlan proposed a "ELPython" last year:
>>
>>https://github.com/elpython/elpython-meta
>
>
> Was that when
>
>
>>
>>
>> The Linux kernel also have multiple LTS kernel which are supported
>> longer than usual releases: they are now supported for 6 years. See
>> "Longterm" at:
>>
>>https://www.kernel.org/category/releases.html
>
>
> The LKM has plenty of paid, full-time employees to keep those LTS kernels
> running upstream while we have nothing close to that. Even if we said "no
> one is expected to manage 3.6 changes" to let paid core devs keep 3.6
> going, that still adds overhead to other core devs who have no interest in
> keeping 3.6 alive for Canonical or RH's benefit (yes, the community gets
> benefits as well, but I would argue the pay-off isn't high enough for
> volunteers to be involved). Now if downstream vendors wanted to get
> together to pool their resources to make 3.6 a LTS-like release in a
> separate repo then I would be fine with that.
>
> I also think this puts Ned in a tough position to say "no" to the request
> if people start saying "I would love more free support!" ;) .
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] discuss.python.org participation

[Gregory P. Smith]

On Tue, Oct 9, 2018 at 8:24 PM Jack Diederich  wrote:

> I'm worried about the new format combined with governance discussions. As
> best I can tell 51 CPython committers have signed up for an account [I
> think that is a big number, btw] but only 17 have posted anything; That 17
> is about 5 more people than put their name on a governance PEP. And maybe 5
> people have half the total posts. This does not feel like a discussion at
> all.
>

I'm not participating in discussions on them because I have limited
bandwidth. I'm waiting to be told we're ready to read PEPs and how to cast
votes.
ie: exactly the same way I behave with mailing lists.

-gps
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Gregory P. Smith]

On Thu, Jul 12, 2018 at 12:17 PM Brett Cannon  wrote:

> On Thu, 12 Jul 2018 at 11:53 Barry Warsaw  wrote:
>
>>
>> That said, I think a triumvirate would work (Guido’s Unworthy Inherited
>> Delegation Organization).
>
>
> Nice! "GUIDO decided ..." Totally going to mess with Guido's personal SEO,
> though. ;)
>

+1  Whatever we wind up with, the name has already been decided.  Lets keep
GUIDO as the name unless the ex-BDFL rejects it!  =)

I *assumed* someone else would've long suggested we act as an autonomous
collective organized as an anarcho-syndicalist commune in honor of
https://youtu.be/Yx_pDo9B0NY by now given the in person conversations where
the Holy Grail quoting of came up. :P  (in case it isn't obvious: *don't
take that seriously*)

In all seriousness, we already have a BDFL delegate system for PEPs that
makes sense.  At a minimum, how to choose the delegate, or early reject a
PEP so it doesn't need one, is the thing we'll decide within the next year.

I also liked some of Raymond H's suggestions around adjusting the PEP
section authorship and potentially final decision acceptance process. But
those types of changes are likely best kept separate from choosing how BDFL
delegates are agreed on. (ie: lets decide how we would even declare the
decision of such changes first)

-gps
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Vote to promote Pablo Salingo Salgado as core developer

[Gregory P. Smith]

Quick response:

+0.5

My first reaction was "really?" given the amount of iteration required due
to lack of CPython extension module API experience demonstrated in the
os.posix_spawn PRs.  (I am not surprised to see Serhiy's negative
reaction)  But Pablo shows drive and desire to do good things and an
ability to eventually do it even if there are learning bumps along the
way.  With mentoring and PR reviews (which I'm assuming Victor is signing
up for) I believe Pablo would make a fine core developer.

So +0.5 from me.  I wouldn't give Pablo free reign to make changes yet -
mentoring required - but that is exactly how most of us start off while we
learn.  I know I started that way.

-gps




On Thu, Jun 14, 2018 at 5:06 AM Victor Stinner  wrote:

> Oh, I forgot to mention that Pablo is already helping me on triagging
> buildbot failures since 1 month.See my email to python-dev for the
> context:
>
> "[Python-Dev] How to watch buildbots?"
> https://mail.python.org/pipermail/python-dev/2018-May/153754.html
>
> You can see his emails on the buildbot-status mailing list:
> https://mail.python.org/mm3/mailman3/lists/buildbot-status.python.org/
>
> Victor
>
> 2018-06-13 18:16 GMT+02:00 Victor Stinner :
> > Hi,
> >
> > I propose to promote Pablo Salingo Salgado as a core developer and so
> > open a vote during one week. If there is no strong opposition, I will
> > promote him but also continue to mentor him for a least one month.
> >
> > Pablo is contributing frequently to Python since almost one year. He
> > added os.preadv()/pwritev() to Python 3.7 and os.posix_spawn() to
> > Python 3.8. I am now waiting for his os.copy_file_range() function!
> > (Others are working on it.)
> > https://bugs.python.org/issue26826
> >
> > I am mentoring Pablo Salingo Salgado since January. I am watching his
> > hard work since last September. He made many non trivial and useful
> > contributions to Python.
> >
> > I think that he understands well how Python is developed, is
> > respectful, try to find answers alone before asking, and is eager to
> > learn. In case of doubt, he ask others before doing something, like
> > closing an issue. I trust that Pablo will respect opinions of others,
> > like not merging a PR if someone disagree.
> >
> > Pablo's merged PR:
> >
> https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Aclosed+is%3Apr+author%3Apablogsal+
> >
> > He got 22 commits merged into master between September 2017 and June
> 2018.
> >
> > If Pablo is promoted as a core developer, I propose to continue to be
> > his mentor for at least one month, and ask him before merging any PR.
> >
> > Note: Pablo already has the bug triage permission for 5 months:
> >
> https://mail.python.org/pipermail/python-committers/2018-January/005133.html
> >
> > Victor
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] A different way to focus discussions

[Gregory P. Smith]

On Fri, May 18, 2018 at 3:28 PM Guido van Rossum  wrote:

> Discussing PEPs on python-dev and python-ideas is clearly not scalable any
> more. (Even python-committers probably doesn't scale too well. :-)
>
> I wonder if it would make sense to require that for each PEP a new GitHub
> *repo* be created whose contents would just be a draft PEP and whose issue
> tracker and PR manager would be used to debate the PEP and propose specific
> changes.
>
> This way the discussion is still public: when the PEP-specific repo is
> created the author(s) can notify python-ideas, and when they are closer to
> submitting they can notify python-dev, but the discussion doesn't attract
> uninformed outsiders as much as python-{dev,ideas} discussions do, and it's
> much easier for outsiders who want to learn more about the proposal to find
> all relevant discussion.
>

overall I think this idea has merit.

flaws?  People who haven't yet given attention to the PEP over in its own
world are likely to spawn the same threads on -ideas or -dev when the PEP
is introduced there.

So long as something is public, there will always be outsiders. It also
seems like using a forum such as a repository full of PRs threads can lose
the discussion history as PRs are not a mailing list archive and can
disappear at the whim of the corporation hosting them.  But do we care
about that?  In theory all arguments and alternatives for/against are
_supposed_ to be captured into the PEP doc itself before it is accepted.

I do like the ability to have a technical code discussion in markdown as
PRs allow vs email.  But if there are 100 people chiming in, I doubt this
would make anything any easier to follow.

PEP authors may also choose to use a different repo hosting site, e.g.
> Bitbucket or GitLab. We can provide a script that allows checking the
> formatting of the PEP easily (basically pep2html.py from the peps repo).
>
> Using a separate repo per PEP has the advantage that people interested in
> a topic can subscribe to all traffic in that repo -- if we were to use the
> tracker of the peps repo you would have to subscribe to all peps traffic.
>

It sounds like your primary goals here are
 (a) to avoid PEP discussions on the -dev and -ideas mailing lists and
 (b) to have a central place for all discussions spawned from a specific
PEP instead of trying to piece together 18 centithreads with varying
subjects from python-* list archives.

I think (a) would happen at the start, and (b) would be true in this
scenario so it is probably worth a try.

I do expect (a) to overflow to the mailing list anyways at times.  But this
would give us the opportunity to redirect that away from the list.  It
should still be better than the common mailing list free for all we have
today.  It seems a bit more like a "working group" system. (which is what
Carol's description of Jupyter incubator reminds me of)

*repos* where PEP discussions take place could optionally be CPython forks
with an example implementation to eventually be used to construct the
ultimate PRs adding it if the PEP is accepted.


> Thoughts? (We can dogfood this proposal too, if there's interest. :-)
>

I'm all for picking a victom^Wvolunteer PEP to try dogfood it on.

-gps
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Travis & AppVeyor hidden on Github, scroll the invisible region to see them.

[Gregory P. Smith]

On Fri, May 18, 2018 at 9:45 AM Terry Reedy  wrote:

> On 5/18/2018 12:25 AM, Gregory P. Smith wrote:
> > VSTS is clearly not yet a stable continuous integration platform.  It
> > needs to be made non-blocking, and AppVeyor and Travis need to be
> > brought back!
> >
> > Examples:
> > https://github.com/python/cpython/pull/6938#issuecomment-389908094
> > Windows broke -
> > https://python.visualstudio.com/cpython/_build?buildId=522
> > https://github.com/python/cpython/pull/6939
> > Linux broke -
> https://python.visualstudio.com/cpython/_build?buildId=523
>
> Travis and AppVeyor are there on both issues, and both can be merged --
> manually -- by pressing 'Squach and merge', even though not green.  The
> VSTS results are not blocking -- they are not marked as 'Required'.


Sorry! A combination of github UX flaws led me to misunderstand what I was
seeing. The things I wanted to see were still run, but they are not
displayed, so I assumed they were gone.  That plus the no green button made
me assume the new things that were displayed containing one red item were
all that there was to see and that they were blocking everything.

There is a hidden secret scrolling region when "show all checks" is active
on github instead of actually showing all.  It only shows five (read: not
the five I want).  The things I wanted to see were at the bottom and thus
not displayed as it puts the VSTS builds up top for some unknown to me
reason.

I am intentionally not merging those PRs yet as I referred to them from
several places as examples of this problem.

The
> problem is that miss-islington was not changed, and sees any VSTS
> failure as a status check failure and a reason to not do the automerge
> you requested by approving the change.
>

That at least we can fix until we trust VSTS to be reliable.  As is, the
more checkers we have to block on, the more likely anything flaky (either
infrastructure or tests+code itself) is to block any given change.

What do people think about teaching miss-islington how to re-launch
specific CI runs a few times to deflake failures? ("1 out of n passes
counts as a pass") - That requires compute resources, but when it is what
the human is going to need to do anyways... why not reduce the need and
just automate it the first couple of times? I don't know how feasible this
is for any given CI system we use today on CPython given the various ways
in which they operate.

-gps


>
> > This was on a documentation-only change.
> >
> > We cannot be changing to new PR-merge-blocking continuous integration
> > services at this point during a release cycle.  This is preventing
> > changes from making it in.
>
> What *is* blocking merges and making them painful at times are the
> haphazard failures of test_asyncio on the blocking bots, Travis and
> AppVeyor, at a rate as high as 1/4 of individual test runs.  See
> https://bugs.python.org/issue33531
> On one backport last night, I had to run Travis 4 times, which means I
> had to periodically monitor the backport instead of approve and forget.
> And then I had to manually merge.
>
> tjr
>
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Bring back Travis & AppVeyor, make VSTS non-blocking

[Gregory P. Smith]

VSTS is clearly not yet a stable continuous integration platform.  It needs
to be made non-blocking, and AppVeyor and Travis need to be brought back!

Examples:
 https://github.com/python/cpython/pull/6938#issuecomment-389908094
   Windows broke -
https://python.visualstudio.com/cpython/_build?buildId=522
 https://github.com/python/cpython/pull/6939
   Linux broke - https://python.visualstudio.com/cpython/_build?buildId=523

This was on a documentation-only change.

We cannot be changing to new PR-merge-blocking continuous integration
services at this point during a release cycle.  This is preventing changes
from making it in.

-gps
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions?

[Gregory P. Smith]

On Wed, May 2, 2018 at 2:49 AM, Victor Stinner  wrote:

> Hi,
>
> I would like to start a poll on Chris Angelico's PEP 572 "Assignment
> Expressions", restricted to Python core developers, to prepare the
> talk at the Language Summit:
>
>https://www.python.org/dev/peps/pep-0572/
>
> The poll is on the *current* PEP. I propose 4 choices:
>
> * +1: you like the PEP
> * -1: you dislike the PEP
> * 0: you are not sure if you like it or not, or you have no opinon
> * don't reply to this poll :-)
>

-1
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email

[Gregory P. Smith]

On Mon, Dec 11, 2017 at 12:26 PM R. David Murray 
wrote:

> On Mon, 11 Dec 2017 14:56:21 -0500, Donald Stufft 
> wrote:
> >
> > > On Dec 11, 2017, at 2:52 PM, R. David Murray 
> wrote:
> > >
> > > If 2fa is required for contribution to CPython, I'll stop
> > > contributing.
> >
> > I’m curious why? I have it on and 99% of the time you don’t even
> > notice because you’re already logged into GitHub and pushes/pulls
> > don’t require it.
>
> I had to use 2FA when working for a corporate client, and it was
> very annoying.  The fact that pushes and pulls don't require it
> helps, but also makes it considerably less important.
>

Please Don't let *that* experience color your 2FA opinion.  Not everyone
$random_corp does a good job of it.

It does not have to be annoying.  Github's and Google's are examples of 2FA
done right that is not annoying (using U2F).

But I suppose that fundamentally I do not want my security tied to a
> possession.
>

*2FA doesn't need to be tied to a single possession.*  You are not limited
to a single second factor thing.  You can have plentiful different two
factor methods set up at once.  This is normal.  ex: A printed recovery
code at the very least as a second second factor.  Have multiple U2F USB
tokens tied to your account? Yes. I do that all the time on all accounts.

Heck, a photo/scan/screenshot of backup one time codes stored as a public
image somewhere with no password authentication for the world to see on an
http server still counts.  As laughable as that is, it is *still* much
better than not having 2FA enabled at all.  Because it isn't going to be an
automated attack at that point.

*Any* 2FA is much better than no 2FA.

When (not if) your login/password is compromised, it is rarely your own
fault. But your account and all of your data can be gone in a heartbeat as
soon as anyone or anything malicious chooses to make it so on whatever
selection of accounts they choose to victimize. Often irrecoverably. With
2FA enabled, that is much less likely to happen to you.

Try it. You will remain happy.

I recommend the https://www.yubico.com/product/yubikey-neo/ as a primary
U2F token because it even works with Chrome on Android phones via NFC when
you need to re-auth there.  That is a more expensive one, there are $10-20
alternative vanilla U2F USB tokens. I have some of those as backups. The
"nano" style keys that you just leave in the USB port of all computers you
use regularly are also a nice solution. no need to find and pull out the
key, it is just present in your computers (it requires a physical touch to
prevent remote access).

Which 2FA methods to choose is an individual choice, but in my experience
since the U2F keys came out, I'm less inclined to use any service that
doesn't support them as all other solutions are a worse user experience for
me.

IMNSHO, the PSF *should* be able to buy one or two U2F tokens for any
committer who needs them.  This should not depend on a policy of 2FA use,
it would just be a way to promote good security practices among committers
to make us all better off.

-Greg
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] autoconf 2.70

[Gregory P. Smith]

I do not think we should require individual developers committing changes
to configure.ac to use a particular version of autoconf when regenerating
configure. That is a burden.

The solution to your problem is to maintain your patches _only_ against
configure.ac and rerun autoconf using whatever version you need yourself.

If a release manager decides they want configure generated with a specific
version of autoconf at release time, they should rerun that specific
version of autoconf and commit the result _for the release_.

otherwise the checked in configure script exists entirely as a convenience.
 configure.ac is always the source of truth.

-gps

On Tue, Nov 22, 2016 at 11:38 PM Xavier de Gaye  wrote:

> On 11/22/2016 08:16 PM, Ned Deily wrote:
>  > On Nov 22, 2016, at 11:06, Xavier de Gaye  wrote:
>  >> The configure file on the default and 3.6 branches have been generated
>  >> with autoconf 2.70 once again. This is annoying when you have to
>  >> maintain patches to this configure file in order to build on a non
>  >> supported platform.
>  >
>  > I'm sorry about that.  I did promise to rerun with autoconf 2.69 before
> tagging the release so committers didn't have to worry about it but I
> didn't notice my note to do so until after 3.6.0b4 had
> already been tagged.  I'll try to do better for rc1.
>  >
>  > Perhaps another solution to the problem might be to not include the
> autoconf-generated changes in the patches and just always run autoconf
> before doing a build?  That's what we suggest for patches
> submitted to the tracker.
>  >
>  > And this might also be a candidate for handling in our upcoming new
> development workflow, i.e. something like having autoconf automatically be
> run as part of checkins.  If it hasn't already been
> discussed there, it might be worth bringing up on the core-workflow
> mailing list.
>  >
>  > --
>  >   Ned Deily
>  >   n...@python.org -- []
>  >
>
>  From the configure logs since last july, it seems that Benjamin and
> Serhiy are
> the only one using autoconf 2.70:
>
>  changeset 102530:b04560c3ce69 - author Benjamin Peterson
>  changeset 103648:816ae3abd928 - author Serhiy Storchaka
>
> If it is not too difficult to build autoconf 2.69 from source, then the
> solution could be that they switch to autoconf 2.69.
>
> Xavier
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Promote Xiang Zhang as a core developer

[Gregory P. Smith]

+1 thanks for mentoring.

On Mon, Nov 21, 2016, 2:14 PM Victor Stinner 
wrote:

> Hi,
>
> 2016-11-21 21:53 GMT+01:00 Brett Cannon :
> > We received an email from Xiang with his SSH keys and GitHub username
> > (although no subscription request for python-committers). Was he finally
> > approved for receiving commit privileges?
>
> (Oh, I forgot to send an email to python-committers.)
>
> Berker Peksağ reported issues on reviews. I proposed to handle these
> issues with mentoring. I asked Xiang to ask me before pushing anything
> during one month. After this period, we can discuss again to continue
> mentoring with the same rule, or maybe change rules or even stop
> mentoring. In short, I commit my responsibility with taking Xiang
> onboard :-)
>
> I counted five positive votes (including myself):
>
> * INADA Naoki
> * Nick Coghlan
> * Senthil Kumaran
> * Serhiy Storchaka
> * Victor Stinner
>
> So, yes, I suggest to take him onboard :-)
>
> Victor
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Davin Potts as a new committer

[Gregory P. Smith]

On Fri, Mar 4, 2016 at 10:07 PM Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:

>
> > On Mar 4, 2016, at 4:07 PM, Brett Cannon  wrote:
> >
> > I guess I'm just worried about the health of this project. I'm doing
> what I can through the migration to GitHub to make it easier for others to
> get involved while making it easier for us to accept the work of others,
> but the maintenance and health of this team worries me. For instance, if
> you look at the developer's log you will notice we only gained 2 core devs
> for all of 2015 and the last one was August 2015:
>
> Last year on this list, I recommended that Davin Potts be granted core
> developer status for his on-going work on the multiprocessing module.  This
> group collectively said no, leaving Davin in an odd and uncomfortable limbo.
>

Huh?  Searching for Davin Potts in my mail, I see a ~27 message long thread
from January 2015 about that.  Many of us were +1 to give him commit rights.

I personally assumed it had happened, but the only objections seemed to be
"lets see some patches first"... That part has happened:

Among the *other* things in my mail with Davin's name mentioned are several
streams of committed patches over the past year or so on multiprocessing
related issues (as expected), including recently.

berker.peksag, martin.panter and serhiy.storchaka have been the primary
committers of said Davin patches.

Let's get Davin a commit bit.

-gps
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

[Gregory P. Smith]

On Mon, Jan 4, 2016 at 12:34 PM R. David Murray 
wrote:

> to have to do some extra work to make the hash links work in the bug
> tracker, since I don't think there's any a priori way to distinguish
> between hg hashes and git hashes.
>

Just ignore the remote possibility of short 32-bit hash prefix collisions
(possible, but infrequent): the way to resolve that is when a hash lookup
fails, to look it up in a translation index of former hg hashes.
 practical.  good enough.

-gps
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Proposed core developer for contributing to multiprocessing

[Gregory P. Smith]

+1 for commit access, Raymond volunteered as a mentor.

I agree with MAL, it is more beneficial to trust people and give out commit
access early.

-gregory.p.smith

On Sat Jan 10 2015 at 9:16:26 AM Ethan Furman  wrote:

> On 01/06/2015 11:09 PM, Raymond Hettinger wrote:
> >
> > I would like to propose Davin Potts as core developer to take on the
> responsibility for maintaining the multiprocessing
> > package.
> >
> > I've been working with him on and off for over a year and found him to
> be highly skilled, thoughtful, and responsible.
> >  He is willing to devote time to a much neglected part of the standard
> library (186 open issues).  He would be a valued
> > member of the team.
> >
> > I would be happy to serve as his mentor for his early contributions.
>
> Having read the thread, and seeing that Raymond is willing to vouch for
> and to mentor Davin, I am
>
> +1
>
> --
> ~Ethan~
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Commit access to PEPs for Ben Hoyt

[Gregory P. Smith]

+1


On Tue, Jul 8, 2014 at 7:06 AM, Eli Bendersky  wrote:

>
>
>
> On Tue, Jul 8, 2014 at 4:18 AM, Victor Stinner 
> wrote:
>
>> Hi,
>>
>> Ben Hoyt (benh...@gmail.com) is working on the os.scandir() PEP 471:
>> http://legacy.python.org/dev/peps/pep-0471/
>>
>> Currently, he send me the PEP text and I update the repository. Would
>> it be possible to give him access to the repository directly? (only to
>> the peps reposistory)
>>
>>
> +1
>
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] review links

[Gregory P. Smith]

actually if your patch contains

"diff -r f4377699fd47 Lib/test/test_zipimport.py"

lines prior to the --- line as hg diff can emit, it'll do the right thing
and show the review against the version of the file listed (or at least
against it's branch head? that's an example taken from 3.3 for a patch that
most definitely does not apply cleanly to default||3.4)

-gps



On Mon, Feb 3, 2014 at 9:20 AM, Antoine Pitrou  wrote:

> On lun., 2014-02-03 at 09:16 -0800, Guido van Rossum wrote:
> > IIRC the review link only appears if the patch applies cleanly.
>
> And only if it applies cleanly on the default branch, IIRC :-)
>
> Regards
>
> Antoine.
>
>
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] clinic churn after beta2

[Gregory P. Smith]

On Tue, Jan 7, 2014 at 4:58 PM, Larry Hastings  wrote:

>  On 01/07/2014 03:10 PM, A.M. Kuchling wrote:
>
> On Tue, Jan 07, 2014 at 02:37:22PM -0800, Eli Bendersky wrote:
>
>  Just to be clear, this is exactly what I mean. I'm not saying AC is not
> worth it; I'm questioning the timing.
>
>  Agreed; let's try to avoid far-ranging sets of changes so late in the
> beta cycle.
>
> If we want to send 3.4 back to alpha and implement some form of
> string-formatting changes and Argument Clinic, that would be fine,
> though it might mean Ubuntu and other Linux distros might have to ship
> with 3.3 again because 3.4 wasn't done in time.
>
>
> I hadn't considered slipping the release, but that does seem like an
> entirely sane idea.  However, I'm not proposing slipping back to alpha so
> we can add the cause-celebre-of-the-week bytes formatting stuff, and we
> don't need to slip all the way back to alpha for Argument Clinic.  A third
> beta seems entirely reasonable though.  Let's try the derby for a couple of
> days and see how we feel.
>
>
+1
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] clinic churn after beta2

[Gregory P. Smith]

On Tue, Jan 7, 2014 at 1:18 PM, Eli Bendersky  wrote:

> Hello,
>
> Does it really make sense to introduce large amounts of code churn after
> the release of 3.4 beta2? It started innocently enough, but now it seems
> that the whole implementation is being reconsidered (Antoine's email to
> pydev). This doesn't look like something we should be doing so late in the
> release process.
>

I wouldn't call that a whole implementation being reconsidered. People are
just bike shedding over which wall to paint first. The color has already
been established.

Besides, Larry is both the release manager for 3.4 and argument clinic
proponent. If we need a beta3 instead of an rc1 next, that is up to him. :)

I'm not weighing in on the pydev thread despite having opinions because it
just doesn't matter to me in the end. I'd just be adding noise and am happy
to accept anything so long as argument clinic does stay in for 3.4.


> Are we really that much in need of convert-to-clinic *now*?
>

It'll never happen otherwise.

-gps
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Temporary revert to vanilla hg

[Gregory P. Smith]

On Fri, Sep 6, 2013 at 7:30 PM, Antoine Pitrou  wrote:

> Le samedi 07 septembre 2013 à 02:03 +0200, Antoine Pitrou a écrit :
> > Hello,
> >
> > I've temporarily reverted hg.python.org to a vanilla Mercurial
> > installation (non-modified) in order to try and eliminate a recent
> > performance problem. This means that server-side clones, and our
> > magnificent logo, have disappeared for the moment.
>
> I've identified the source of the problem:
> http://bz.selenic.com/show_bug.cgi?id=4031
>
> I've now downgraded the Mercurial installation to 2.6.3 and re-applied
> our scrumptious modifications.
>

any chance mercurial would accept our scrumptious modifications upstream?
 server side clones at least seems like a feature many hg users would like.

-gps


> Regards
>
> Antoine.
>
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] what's going on with Misc/NEWS?

[Gregory P. Smith]

On May 26, 2013 1:15 PM, "Brett Cannon"  wrote:
>
>
> On May 25, 2013 9:18 PM, "Nick Coghlan"  wrote:
> >
> > On Sun, May 26, 2013 at 9:41 AM, Brett Cannon  wrote:
> > >> The NEWS update script could even use the revision history to decide
> > >> which order to add entries to the bulleted list.
> > >
> > > I think the annoyance with this approach is you will have to remember
> > > to add a file every time you do anything worthy of NEWS. Without
> > > something like ``hg newsworthy`` to take an optional issue # and then
> > > have you enter your NEWS entry and then use that to pre-populate the
> > > commit message, people will forget. Now granted adding the commit
> > > later is not a huge deal, but it is something that might happen if you
> > > forget to ``hg st`` before committing.
> >
> > How is that any different from the status quo with people forgetting
> > an entry in NEWS? Just the extra step of needing to "hg add" the news
> > entry?
>
> I didn't think there was a forgetfulness issue. I'm just trying to lower
the overhead of doing a merge.
>
> >
> > Well, perhaps we can do this in two phases - resolve the persistent
> > problem of merge conflicts first, and then worry about the separate
> > push race problem later.
>
> If we can ever agree on a solution. :)

If people are still allowed to edit Misc/NEWS manually while a tools and
alternatives are worked out that ultimately merge their entries into the
original file at release time I think no agreement is needed beyond from
the release managers who presumably get to ensure it all happens to
generate the single file at tag/branch time.

Try a few things out, see what sticks and vote on what the ultimate
solution for everyone should be at that point.

>
> -brett
>
> >
> > Cheers,
> > Nick.
> >
> > --
> > Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] what's going on with Misc/NEWS?

[Gregory P. Smith]

On May 25, 2013 8:29 AM, "Gregory P. Smith"  wrote:
>
>
> On May 25, 2013 1:40 AM, "Nick Coghlan"  wrote:
> >
> > On Sat, May 25, 2013 at 2:01 PM, Eric Snow 
wrote:
> > > On Fri, May 24, 2013 at 9:46 PM, Raymond Hettinger
> > >  wrote:
> > >> and it recognizes that users don't really need to look across merge
> > >> boundaries.
> > >
> > > This is tricky though for any patch that is forward-ported to a
> > > release branch (a la 3.2->3.3).  How can you tell from MISC/News in
> > > which release (e.g. 3.3.0 or 3.3.1) of that branch the bug was fixed?
> > > The entry would only show up in MISC/News for the previous release
> > > (e.g. 3.2.3).
> > >
> > > Granted, this would impact much fewer patches than our current pain
point does.
> >
> > Let's take a step back for a moment and define the workflows we want to
handle.
> >
> > 1. Feature development
> >
> > - simplest case
> > - just edit Misc/NEWS on default
> >
> > 2. Normal 3.x only bug fix
> >
> > - second simplest case
> > - exit Misc/NEWS on 3.3
> > - merge to default
> > - frequently conflict (due to entries for new features and different
> > release headers)
> > 
> >
> > OK, I'm going to stop enumerating the cases there, because it already
> > suggests to me that splitting the *whole* NEWS file entirely by
> > version is the wrong thing to do. Instead, we really only need to
> > split the handling for NEWS items that haven't been released yet.
> >
> > To avoid needing to copy info from other branches between files when
> > doing a merge, we could instead set up the following:
> >
> > 1. Add a new directory called NEWS.next
> > 2. New NEWS entries go in version specific files in that directory
> > 3. When a new release is made, ALL entries in NEWS.next are added to
> > the top of the main NEWS file for the relevant (a script to help with
> > the merging would be a good idea) and the contents of NEWS.next are
> > cleared.
> >
> > So, suppose we're about to release 3.4.0a1. In the meantime, we have
> > accumulated bug fixes for 3.3 and new features and bug fixes that
> > couldn't be backported for 3.4. (The scheme could be extended to
> > security branches too, but I'm assuming for the moment those will be
> > handled via selective backporting rather than the normal forward
> > porting path)
> >
> > The 3.3 branch layout would look like this:
> >
> > NEWS.next/
> > 3.3.txt  # Categorised changes
> > NEWS  # Existing partial entry for 3.3.x
> >
> > The default branch layout would look like this:
> >
> > NEWS.next/
> > 3.3.txt  # Forward ported categorised changes
> > 3.4.txt  # Categorised changes
> >NEWS  # Existing partial entry for 3.4.0a1
> >
> > Any changes that were specific to 3.3 would be listed in
> > NEWS.next/3.3.txt on that branch, but not on the default branch (since
> > the associated null-merge would have skipped adding them)
> >
> > Now, we go to create 3.4.0a1. This will involve transferring *all* the
> > NEWS.next entries on default into the main NEWS file and clearing the
> > files in NEWS.next.
> >
> > NEWS.next/
> > 3.3.txt  # Empty file
> > 3.4.txt  # Empty file
> >NEWS  # Complete entry for 3.4.0
> >
> > The part I'm not clear on is whether we'd then start getting conflicts
> > when forwarding merging changes to NEWS.next/3.3.txt from the 3.3
> > branch, or if Mercurial would be smart enough to cope with the
> > deletion for the file contents and not try to add them back in. If it
> > can't cope, then it would be possible to do the following on 3.3 when
> > creating the initial 3.4.0a1 release:
> >
> > NEWS.next/
> > 3.3.txt  # Empty file
> >NEWS  # Longer partial entry for 3.3.x
> >
> > We then continuing accumulating NEWS.next entries in parallel during
> > the 3.4 alpha and beta cycle, moving the entries into the appropriate
> > NEWS files as releases are made.
> >
> > The other advantage of this is that it's an approach we can adopt
> > *today*, so long as we acknowledge we'll need the tooling to merge the
> > NEWS entries and clear NEWS.next before we can next do a release for
> > 3.3 and 3.4, and Georg and Larry are happy with that notion.
> >
>
> I like where you're heading with this but it still leaves merges during
Spruits and when a few people are working at once by putting stuff in a
single file.

sprints

>
> Per news item / per issue files for each release that are riled up into
the actual news file by a release manager run script & commit at release
time make more sense.
>
> > Cheers,
> > Nick.
> >
> > --
> > Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> > ___
> > python-committers mailing list
> > python-committers@python.org
> > http://mail.python.org/mailman/listinfo/python-committers
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] what's going on with Misc/NEWS?

[Gregory P. Smith]

On May 25, 2013 1:40 AM, "Nick Coghlan"  wrote:
>
> On Sat, May 25, 2013 at 2:01 PM, Eric Snow 
wrote:
> > On Fri, May 24, 2013 at 9:46 PM, Raymond Hettinger
> >  wrote:
> >> and it recognizes that users don't really need to look across merge
> >> boundaries.
> >
> > This is tricky though for any patch that is forward-ported to a
> > release branch (a la 3.2->3.3).  How can you tell from MISC/News in
> > which release (e.g. 3.3.0 or 3.3.1) of that branch the bug was fixed?
> > The entry would only show up in MISC/News for the previous release
> > (e.g. 3.2.3).
> >
> > Granted, this would impact much fewer patches than our current pain
point does.
>
> Let's take a step back for a moment and define the workflows we want to
handle.
>
> 1. Feature development
>
> - simplest case
> - just edit Misc/NEWS on default
>
> 2. Normal 3.x only bug fix
>
> - second simplest case
> - exit Misc/NEWS on 3.3
> - merge to default
> - frequently conflict (due to entries for new features and different
> release headers)
> 
>
> OK, I'm going to stop enumerating the cases there, because it already
> suggests to me that splitting the *whole* NEWS file entirely by
> version is the wrong thing to do. Instead, we really only need to
> split the handling for NEWS items that haven't been released yet.
>
> To avoid needing to copy info from other branches between files when
> doing a merge, we could instead set up the following:
>
> 1. Add a new directory called NEWS.next
> 2. New NEWS entries go in version specific files in that directory
> 3. When a new release is made, ALL entries in NEWS.next are added to
> the top of the main NEWS file for the relevant (a script to help with
> the merging would be a good idea) and the contents of NEWS.next are
> cleared.
>
> So, suppose we're about to release 3.4.0a1. In the meantime, we have
> accumulated bug fixes for 3.3 and new features and bug fixes that
> couldn't be backported for 3.4. (The scheme could be extended to
> security branches too, but I'm assuming for the moment those will be
> handled via selective backporting rather than the normal forward
> porting path)
>
> The 3.3 branch layout would look like this:
>
> NEWS.next/
> 3.3.txt  # Categorised changes
> NEWS  # Existing partial entry for 3.3.x
>
> The default branch layout would look like this:
>
> NEWS.next/
> 3.3.txt  # Forward ported categorised changes
> 3.4.txt  # Categorised changes
>NEWS  # Existing partial entry for 3.4.0a1
>
> Any changes that were specific to 3.3 would be listed in
> NEWS.next/3.3.txt on that branch, but not on the default branch (since
> the associated null-merge would have skipped adding them)
>
> Now, we go to create 3.4.0a1. This will involve transferring *all* the
> NEWS.next entries on default into the main NEWS file and clearing the
> files in NEWS.next.
>
> NEWS.next/
> 3.3.txt  # Empty file
> 3.4.txt  # Empty file
>NEWS  # Complete entry for 3.4.0
>
> The part I'm not clear on is whether we'd then start getting conflicts
> when forwarding merging changes to NEWS.next/3.3.txt from the 3.3
> branch, or if Mercurial would be smart enough to cope with the
> deletion for the file contents and not try to add them back in. If it
> can't cope, then it would be possible to do the following on 3.3 when
> creating the initial 3.4.0a1 release:
>
> NEWS.next/
> 3.3.txt  # Empty file
>NEWS  # Longer partial entry for 3.3.x
>
> We then continuing accumulating NEWS.next entries in parallel during
> the 3.4 alpha and beta cycle, moving the entries into the appropriate
> NEWS files as releases are made.
>
> The other advantage of this is that it's an approach we can adopt
> *today*, so long as we acknowledge we'll need the tooling to merge the
> NEWS entries and clear NEWS.next before we can next do a release for
> 3.3 and 3.4, and Georg and Larry are happy with that notion.
>

I like where you're heading with this but it still leaves merges during
Spruits and when a few people are working at once by putting stuff in a
single file.

Per news item / per issue files for each release that are riled up into the
actual news file by a release manager run script & commit at release time
make more sense.

> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] what's going on with Misc/NEWS?

[Gregory P. Smith]

On May 24, 2013 2:55 PM, "Antoine Pitrou"  wrote:
>
> Le vendredi 24 mai 2013 à 16:22 -0400, Brett Cannon a écrit :
> > >
> > > I don't understand why it's painful to backport. Can you explain?
> >
> > If I make a very minor fix to the docs I have to:
> >
> > # In a 3.3 checkout
> > Fix docs
> > Compile docs
> > Add Misc/NEWS entry
> > hg ci -m "repeat what I just said in Misc/NEWS"
> > hg push
> > cd ../default
> > hg merge 3.3
> > Fix/revert Misc/NEWS (at least)
> > Compile docs (if fix is needed)
> > hg ci
> > hg push
>
> I honestly don't understand why you would mention doc fixes (even major
> ones) in Misc/NEWS. It's not a useful piece of information to have
> there. People want to know about bug fixes because they are affected by
> bugs, but doc fixes??

I think you misunderstood what he meant. Misc/NEWS is documentation. I
believe he meant he won't fix typos in NEWS due to the make pain involved.

I'm the same way. I want nothing to do with news when making my changes
because it ALWAYS gets in the way for any change not being done on
head/default/tip only. If anything I prefer to leave news entries out of
the commit they are related to to avoid news merges going wrong from
messing up the real change. Hopefully I remember to write a news entry for
it after the fact.

>
> Regards
>
> Antoine.
>
>
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] what's going on with Misc/NEWS?

[Gregory P. Smith]

On May 24, 2013 2:26 PM, "Benjamin Peterson"  wrote:
>
> 2013/5/24 Brett Cannon :
> > It's an extreme example, but for instance I added an entry for this
> > sys.modules change where I just added a clarifying sentence. Probably
> > not needed but wanted to make sure that people got the message they
> > shouldn't replace sys.modules.
>
> Does anybody actually read Misc/NEWS?
>

Yes. It's the best way to get a summary of what changed in a release with
more little details than any higher level what's new docs and without
looking at diffs.

>
> --
> Regards,
> Benjamin
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Googler Python committers

[Gregory P. Smith]

On Tue, Oct 16, 2012 at 5:06 PM, Anthony Baxter wrote:

> Yep. People tend to stop being so active when they join Google (including
> me) :-(
>
My activity increased.  I would not make that statement.

-gps
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Googler Python committers

[Gregory P. Smith]

On Tue, Oct 16, 2012 at 7:44 AM, Chris Jerdonek wrote:

> On Tue, Oct 16, 2012 at 6:32 AM, Eli Bendersky  wrote:
> >
> > I had the privilege of joining Google's Mountain View office yesterday,
> and
> > was wondering who else from the core development team works there, or in
> > Google in general (in addition to Guido, of course).
>
> Congrats, Eli!  This may not be complete or accurate, but (and this
> tip can be useful to everybody), the list of committers here has a
> column that in some cases shows a company.  Several people from Google
> are listed:
>
>
> http://bugs.python.org/user?iscommitter=1&@action=search&@sort=username&@pagesize=300


That isn't up to date and users cannot edit their own information (at least
it tells _me_ I'm not authorized when I submit the edit form on my own
info) so I wouldn't trust that page.  Yet another silly profile to maintain
in yet another location.  sigh.

There are many Google committers though not all are active.

-gps
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Commit privileges for Eric Snow

[Gregory P. Smith]

+1

He doesn't already have them? Blink.

--
got tyops? this was quickly tapped out on a touch screen.
On Aug 23, 2012 4:59 PM, "Nick Coghlan"  wrote:

> I'd like to propose granting Eric Snow commit privileges.
>
> He's been contributing for a couple of years, mostly working on the
> import system replacement with Brett and participating in design
> discussions on import-sig, but also contributing to patches and
> discussions relating to the core compiler and code execution
> machinery.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
>
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] fyi - openssl vulnerability - likely in our windows builds

[Gregory P. Smith]

On Mon, Apr 23, 2012 at 2:42 PM,  wrote:

>  I don't see any occurrence of these functions in the various versions of
>> the _ssl module.
>> Is Python really affected by this vulnerability?
>>
>
> We use SSL_CTX_use_certificate_chain_**file, which ultimately uses
> d2i_X509_AUX_fp (I think).
>
> However, I fail to see how this constitutes are remote vulnerability:
> one would have to inject a bad PEM file into an application to trigger
> this.
>
> http://isc.sans.edu/diary.**html?storyid=13018
>
> claims that this is *not* exploitable over TLS (and I agree); they
> warn that it can be exploited e.g. when Apache reads server certificates
> from untrusted users. Even in the local case, you need a Python application
> running under one account that reads certificate files belonging to
> a different (Unix) account to create an exploit.
>
> So I propose that for the regular bugfix releases, we upgrade the OpenSSL
> version, but otherwise take no action at this point.
>

give that, agreed.
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] fyi - openssl vulnerability - likely in our windows builds

[Gregory P. Smith]

FYI - there is a network exploitable vulnerability in OpenSSL -
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-2110

Our windows builds likely need updating.  At the very least make sure
openssl is updated before the next time we produce binaries. Its up to the
release managers if they want to make a new windows only sub-release to
include the updated version of openssl.

-gps
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Time to cut new rc2 release candidates - expat DoS fix is in

[Gregory P. Smith]

On Wed, Mar 14, 2012 at 6:35 PM, Benjamin Peterson wrote:

> 2012/3/14 Gregory P. Smith :
> > The fixes for the expat hash randomization DoS are in and working -
> > http://bugs.python.org/issue14234.  New stable and security fix rc2
> release
> > candidates should be created for 2.6, 2.7, 3.1 and 3.2.
>
> Okay. Can you tell me the commits I need to transplant to the 2.7
> release branch?
>
>
For 2.7:
  http://hg.python.org/cpython/rev/b54f5849013c
  http://hg.python.org/cpython/rev/cb72aa8a8008

For 2.6:
  http://hg.python.org/cpython/rev/9c8d066013ea

For 3.2:
  http://hg.python.org/cpython/rev/d6c197edd99b
  http://hg.python.org/cpython/rev/b2d4a6a9463e

For 3.1:
  http://hg.python.org/cpython/rev/7b5bc1719477


2.6 and 3.1 only need to transplant one commit as they don't support
--with-system-expat.
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] Time to cut new rc2 release candidates - expat DoS fix is in

[Gregory P. Smith]

The fixes for the expat hash randomization DoS are in and working -
http://bugs.python.org/issue14234.  New stable and security fix rc2 release
candidates should be created for 2.6, 2.7, 3.1 and 3.2.

Barry and MvL agreed that this weekend should work for them to creating
release builds.

-gps
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Python Language Summit at PyCon US

[Gregory P. Smith]

On Mon, Feb 6, 2012 at 2:02 PM, Michael Foord  wrote:
>
> On 6 Feb 2012, at 21:55, Brett Cannon wrote:
>
>>
>>
>> On Tue, Jan 10, 2012 at 08:04, Michael Foord  
>> wrote:
>> Hello Python Committers,
>>
>> As usual we will hold a Python Language Summit before the PyCon US 
>> conference.
>>
>> The language summit will be in the conference hotel, to discuss the ongoing 
>> development of the Python language. It will be held on the  *Wednesday* 
>> before the conference (Wednesday 7th March), a change from previous years.
>>
>> The language summit is an invite only event. All Python core developers, 
>> plus selected others, are invited. If you would like to attend, for all or 
>> part of the day, please respond off list to me so I can keep a track of 
>> numbers.
>>
>> If you have topics you would like to see on the agenda please also let me 
>> know.
>>
>> With the importlib bootstrap work close to being done (just minor 
>> compatibility issues at this point), it probably wouldn't hurt to discuss 
>> what exactly needs to be done to allow the merging of the code to happen (if 
>> any).
>
>
> Added. We have a healthier looking list of topics to discuss now.
>
>
> Which namespace PEP (382 or 402, if either) is to be accepted for 3.3. Barry 
> Warsaw
>
> How can the PSF help alternate implementations. Steve Holden
>
> Experimental packages in the standard library.
>
> Splitting out standard library into a separate repo. Barry Warsaw
>
> Proposed changes to the release cycle (and LTS releases).
>
> What we can do to get speed.python.org going. And all of this plays into what 
> the other VMs need from CPython for Python 3 support to be easier. Brett 
> Cannon
>
> What can be done in Python 3 to make web development easier.
>
> virtualenv-like functionality in Python. Vinay Sajip and Carl Meyer
>
> importlib bootstrap -- Brett
>

Could we collect links to some background reading (whether they be
mailing list threads, blog posts, + posts, etc) on each of the topics
(wiki page?) and send that out several days before the meeting so that
more of us can be up to speed beforehand?

For example I'm not up on the current issues impacting web development
under Python 3 and I doubt I'm the only one (or if I am, yay me!).

-gps
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Merge cleanup reminder

[Gregory P. Smith]

On Sun, May 29, 2011 at 3:00 AM, Ned Deily  wrote:

> Just a reminder and an FYI: the repo was left yesterday with an unmerged
> change leaving the 3.2 branch open.  When you're finished pushing
> changes, it's always a good head idea to do an "hg branches" and make
> sure that only the default (py3k) and 2.7 branches are open:
>
> $ hg branches
> default70473:e8e8a9dbc3c0
> 2.770470:8349094d1fe8
> 3.270472:791c64fdc405 (inactive)
> 3.170471:bd49031b9488 (inactive)
> 2.670460:23340842e920 (inactive)
> 2.570459:0072a98566c7 (inactive)
>
> Since I needed to push some test failure fixes (Issue12205) before the
> 2.7.2/3.1.4 cutoffs today, I took the liberty of doing a null merge to
> record.  Greg, you might want to double-check that all is as you
> intended.
>
> changeset:   70469:ad3c204cc397
> parent:  70468:c5bd972391cd
> parent:  70465:4f248dd34dd9
> user:Ned Deily 
> date:Sun May 29 02:16:36 2011 -0700
> files:   Lib/test/test_subprocess.py
> description:
> Null merge to record previous incorrecly merged changeset from 3.2
>

Thanks.  It looks like I did my merge incorrectly, I'll revisit my hg
procedures.

*flogs self*
-gps



> branch:
> changeset:   70465:4f248dd34dd9
> branch:  3.2
> parent:  70463:7f2e3c466d57
> user:Gregory P. Smith 
> date:Sat May 28 09:06:02 2011 -0700
> files:   Lib/test/test_subprocess.py
> description:
> Fix ProcessTestCasePOSIXPurePython to test the module from import when
>
> changeset:   70466:2c91045d16a6
> parent:  70464:2936e8f12e4f
> user:Gregory P. Smith 
> date:Sat May 28 09:06:02 2011 -0700
> files:   Lib/test/test_subprocess.py
> description:
> Fix ProcessTestCasePOSIXPurePython to test the module from import when
>
> --
>  Ned Deily,
>  n...@acm.org
>
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
>
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Charles-François Natali (neologix)

[Gregory P. Smith]

+1
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] New committer proposal: Alexander Belopolsky

[Gregory P. Smith]

+1

On May 20, 2010 1:28 PM, "Mark Dickinson"  wrote:

I propose that Alexander Belopolsky be given svn commit access.  I've
already checked with him that he's interested (he is), and I'm
prepared to mentor him while he's learning the ropes.

A brief history: Alexander's been contributing patches for almost
seven years (I think http://bugs.python.org/issue798269 is the first);
in that time he's provided numerous patches, comments, and patch
reviews.  Just as a guide, a quick search on bugs.python.org shows
that he's nosy on over 200 issues.  I've recently worked closely with
him on a couple of patches, and think he's ready for commit rights.

In particular, I think it would be great to have his help with the
datetime module, which is in currently need of some care and
attention.

Any objections or comments?

Mark
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Untabifying the C codebase

[Gregory P. Smith]

On Sun, May 9, 2010 at 1:22 PM, Antoine Pitrou  wrote:
> Le dimanche 09 mai 2010 à 22:04 +0200, Victor Stinner a écrit :
>> Le dimanche 09 mai 2010 18:56:27, Antoine Pitrou a écrit :
>> > This was done in r81029 (trunk), r81031 (2.6), r81032 (3.x) and r81033
>> > (3.1). I'm mentioning the revision numbers because it seems
>> > python-checkins blocked the diffs, sensibly enough.
>>
>> Does "make patchcheck" detect tab indentation and trailing spaces 
>> regressions?
>
> No. As a matter of fact, I've never used "make patchcheck" and therefore
> always forget about its existence. Do you want to propose a patch for
> this?
>
>> > If you have patches pending and they don't apply cleanly anymore, you
>> > can either:
>> >  - use "patch -l", and then reformat the modified lines manually
>> >  - use "untabify.py -p" on your patch
>> > (http://svn.python.org/view/*checkout*/sandbox/trunk/untabify/untabify.py)
>>
>> Is it documented somewhere? In the developer FAQ?
>
> I don't think it should go into the developer FAQ, since it's only a
> temporary situation. IMHO it's sufficient to tell people about it when
> they ask on the tracker, or even to do the reformatting ourselves.
>
> (I don't think there are many patches pending on the set of modified
> files, but I could be mistaken)
>
> Regards
>
> Antoine.

fwiw, untabify.py seemed to work fine to keep the change I had in my
svn client in shape across this update.

 svn diff Modules/threadmodule.c >foo.diff
 svn revert Modules/threadmodule.c
 svn up  # update past the untabify changes
 ../untabify.py foo-untabbed.diff
 patch -p0 http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Proposing Tim Golden as a Committer

[Gregory P. Smith]

On Mon, Apr 19, 2010 at 4:07 PM, Mark Hammond  wrote:
> On 20/04/2010 4:51 AM, Michael Foord wrote:
>>
>> Hello all,
>>
>> I would like to propose Tim Golden as a Python committer. He has been
>> involved in Python for many years, is a capable Windows guy, and has
>> submitted many patches / documentation fixes - particularly for Windows
>> issues.
>
> +1 - he has been an excellent contributor of code and wisdom to pywin32 and
> its users...

+1
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] pybsddb 5.0.0 integration and 2.7beta1 schedule

[Gregory P. Smith]

On Tue, Apr 6, 2010 at 11:39 AM, Jesus Cea  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Oracle just released Berkeley DB 5.0.21, with features like SQLite façade.
>
> I am now testing pybsddb 5.0.0, that supports BDB 5.0.x.
>
> My original plan was to delay integration of pybsddb 5.x.x for 2.7.1
> release, but Larry Hastings has a (sensible) request to migrate pybsddb
> from CObject to Capsule for 2.7.0. Current pybsddb 5.0.0 already
> contains that change.

After 2.7.0 is released we can't make any API change like the CObject
to Capsule migration.  I'd go ahead and get that in (if not for beta1,
make sure it is in before beta2).

Tiny tweaks to support compiling against a new BerkeleyDB version that
has the typical minor changes to their API has been done in the past
on .1 or .2 releases as it makes that version of Python last longer as
far as what external libraries it can link against.  I wouldn't object
to that, though I really don't expect there is high demand for that
anymore.

> I am reluctant to integrate the code change before beta1, because
> although it should be transparent I don't want to risk a red buildbot,
> even for 20 minutes, so close to beta1. Integrating it between beta1 and
> beta2 would be riskless, but it would break API compatibility (because
> the CObject->Capsule) change.
>
> I don't know how many people depend of the pybsddb C api, although I
> think that very little.

agreed, probably not many.

>
> What should I do?. When is the beta1 window closed?
>
> PS: I would need a couple of hours for integration, but beware timezone!
> (Spain :).
>
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] branches and merging

[Gregory P. Smith]

On Mon, Mar 1, 2010 at 1:16 AM, Eric Smith  wrote:
> Steven Bethard wrote:
>>
>> I'm preparing the argparse module for the 2.7 and 3.2 branches. Could
>> someone remind me again what the commit process is? Commit to 2.7 and
>> merge to 3.2? And do we merge with svnmerge.py or svn merge? There's
>> probably a webpage explaining this somewhere, but my Google-fu is
>> failing me right now.
>
> http://www.python.org/dev/faq/#how-do-i-merge-between-branches
>
> Use svnmerge.py. Commit to trunk, then merge to py3k. You'll probably want
> to block release26-maint and release31-maint.
>
> Eric.

Why bother explicitly blocking it in release26-maint and
release31-maint?  That just seems like extra svn makework given it
won't be merged into those branches anyways as a matter of policy.

-gps
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Commit access for David Malcolm

[Gregory P. Smith]

On Sat, Feb 20, 2010 at 12:32 PM, Jeffrey Yasskin  wrote:
> Hi all,
>
> David Malcolm is the Fedora maintainer for the Python package and has
> written a gdb plugin to replace and dramatically improve our old
> Misc/gdbinit file using the new python scripting support in gdb-7. You
> can see it in action at
> http://fedoraproject.org/wiki/Features/EasierPythonDebugging#User_Experience.
> I'd like to get this into our repository asap, but he's also going to
> be improving it fairly quickly. So it'd be nice if he could commit his
> improvements directly.
>
> Do you guys think we should give him commit access so he can make gdb
> and packaging-related changes?

+1
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Misc/NEWS entries added to released versions

[Gregory P. Smith]

On Sun, Sep 13, 2009 at 8:54 AM, Matthias Klose  wrote:
> On 06.04.2009 00:33, Matthias Klose wrote:
>>
>> While looking at the diffs between the 261 release tags and the 26 branch,
>> I
>> noticed many items in Misc/NEWS appearing in the 2.6.1 or even 2.6
>> sections.
>> I moved all of these to 2.6.2, after checking some of them, and found all
>> of the
>> checked ones be backported after the 2.6.1 release. Is there anything what
>> could
>> be done to avoid these wrong merges?
>>
>> I plan to check the items on the 3.0 branch soon.
>
> done again for the 2.6.3 (2.6 branch) and 3.1.2 (3.1 branch) entries. I
> didn't check if these were inserted to earlier entries by intent except for
> the removal of the entry for issue #2522.
>
>  Matthias

Thanks.  One reason this happens is that our NEWS file is very
difficult to navigate.  svnmerge rarely works on it because the
context is often different in the branch file but figuring out which
version's section of the bazillion line file you are currently in is
very tedious in a text editor.

brainstorm:

It'd be nicer if we could generate the file from another source,
perhaps keep each releases news in its own file and merge it all
together at release time?

Or have a NEWS.latest file that contains only updates since the
previous release (part of making a release would be to prepend
NEWS.latest to the NEWS file and truncate NEWS.latest)?
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] www & svn . python.org down?

[Gregory P. Smith]

i assume someone already knows, just pointing it out.
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] help with svnmerge

[Gregory P. Smith]

I think those instructions are for merging lots of things at once.

What I've used when I'm merging a single revision is this:

g...@pts/6.dealer/9:46AM% svn up
~/sandbox/python/release26-maint
At revision 70301.
g...@pts/6.dealer/9:47AM% python ../svnmerge.py merge -r70197
property 'svnmerge-integrated' deleted from '.'.

property 'svnmerge-blocked' deleted from '.'.

--- Merging r70197 into '.':
UDoc/library/bsddb.rst

property 'svnmerge-integrated' set on '.'

property 'svnmerge-blocked' set on '.'

g...@pts/6.dealer/9:49AM% ls *.txt
~/sandbox/python/release26-maint
svnmerge-commit-message.txt


Anyways, I just committed the above merge as r70302.


On Tue, Mar 10, 2009 at 7:59 AM, Jesus Cea  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I committed r70197 to trunk a few days ago. Today I copied "svnmerge.py"
> in my 2.6 branch, and did an "init" and a "merge"... like it is said in
> the developer FAQ. I got a lot of conflicts and "old patches" merged.
> Overhelming.
>
> So...
>
> Can anybody please merge r70197 to 2.6 branch?
>
> Can somebody explain how to do a correct svnmerge and, possibly, update
> http://www.python.org/dev/faq/#how-do-i-merge-between-branches ?
>
> Sorry for this inconvenience. I promise to learn the lessons you teach me.
>
> PS: I know how to merge using pure SVN and Mercurial... O:-)
>
> - --
> Jesus Cea Avion _/_/  _/_/_/_/_/_/
> j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
> jabber / xmpp:j...@jabber.org  _/_/
>  _/_/  _/_/_/_/_/
> .  _/_/  _/_/_/_/  _/_/  _/_/
> "Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
> "My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.8 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iQCVAwUBSbaAR5lgi5GaxT1NAQKE1gP9E0b2e8lRwBouayLHuk9cDTrVOJo12Mad
> mZ/dDAzPo4I6dHXkns4PEt8/m2NhCvOFW0abt51bFLVoKUSomuPyxvT9hie/z2wq
> Ra/+czIRjdbwFrk6WeZW7kURIgBDA5OG35p/34LsnhVi/+3JNW42uQRRjusRYO3m
> iUtCCpOdDnw=
> =UpbJ
> -END PGP SIGNATURE-
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
>
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] build dependency on the branches on sphinx trunk necessary?

[Gregory P. Smith]

On Mon, Jan 26, 2009 at 1:59 PM, Matthias Klose  wrote:

> Guido van Rossum schrieb:
> > On Mon, Jan 26, 2009 at 1:27 PM, Matthias Klose  wrote:
> >> Guido van Rossum schrieb:
> >>> I'm not sure I understand your request. Is it okay to build docs using
> >>> a version of sphinx that is included in the distro? Is there a
> >>> specific revision that you would like to see rolled back, or do you
> >>> have a specific fix in mind?
> >> the specific change was committed in r68428. I didn't check if reverting
> this
> >> causes regressions in building the docs.
> >>
> >> A safe approach would be to only use build dependencies on a branch
> which were
> >> released before the first release of the branch. I assume in this case,
> the
> >> branch should stick with sphinx-0.5 and not rely on newer sphinx
> versions (or
> >> sphinx dependencies which were released after the python-2.6.0 release).
> >
> > This seems rather restrictive. It would mean that if we found a bug in
> > sphinx-0.5 that was fixed later in sphinx development we couldn't
> > depend on the bug being fixed for the lifetime of Python 2.6, to
> > satisfy this requirement. Ditto for new sphinx features that might
> > make life easier for the doc authors, or in some cases enable new
> > types of markup that would clarify the docs. It would make backporting
> > doc-fixes from 2.7 harder too.
>
> the rationale for this proposal is that when a Linux distribution does
> freeze
> for a release, only bug fixes are allowed during the freeze until the
> release.
> If you do consider a new release on the branch as a bug fix release which
> can be
> allowed during a freeze, but it depends on a new upstream release of it's
> build
> dependencies we still cannot include it because of the tightened build
> dependency.


Chances are very high that if you grab a copy of sphinx from svn on the date
of the python X.Y release in question that the docs for any updates to that
.Y release will always build using that sphinx.  If not, its up to you as
the interested party to fix/patch them.  I doubt that'll be much work.


>
> > I could live with "only depend on released versions of anything" but I
> > don't think I could live with "don't depend on anything released after
> > 2.6.0 was released" (which IIUC is what you are proposing here).
>
> I could live with a "don't depend on anything released after 2.6.0 was
> released,
> unless it is a bug fix release", e.g. allowing sphinx-0.5.x releases
> (assuming
> these don't have new features).
>
> I don't know of any other open source software which allows unlimited
> changes on
> the build requirements in this way on a release branch.


As a developer I don't consider the documentation to be a critical part of
the build since it isn't strictly tied to a particular release of python,
afaict they're only -guaranteed- to build using a sphinx available at the
time of any given release because that is what was used to make the release.
 Nothing else.

Bundling the required version of sphinx with future Python releases as Guido
suggests is not a bad idea.

If you want to pick a sphinx version to use with a particular python build,
find the date of the release tag for that python version and sync to sphinx
at that date.  It'll be up to you (debian package maintainers) to make sure
that the docs keep building with that version of sphinx within that release
branch.  That could involve patches if someone commits something that breaks
your assumption.  But lets be realistic: documentation changes post-release
are rare.  It won't be much, if any, work for the debian package maintainer.

-Greg
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers