[python-committers] Re: core-dev chat

[Matthias Klose]

On 5/14/21 12:28 PM, Victor Stinner wrote:
> Hi,
> 
> I'm always connected to IRC #python-dev (Freenode) for 10 years, a few
> other core devs use it time to time. Come to say hello ;-)
> 
> The bugs.python.org and buildbot notifications are useful to me and I
> don't feel annoyed by them. But GitHub review are hard to use: only
> the user name and the PR number are given: PR title and comment
> content are not provided, you have to click on each link to know more.
> Moreover, when a user leaves 10 comments, there are 10 IRC
> notifications!

Using #python-dev here as well, but with 99% of the messages being bot messages
it makes it hard to see the real in-person discussions.  Not saying that it's
not useful, but a separate IRC channel for these might be more welcoming for
#python-dev, independent of this discussions about other platforms.

Matthias
___
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/FLPNMXWN6HUPEICFG5KMY77UA5EUEKSY/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Notification of a three-month ban from Python core development

[Matthias Klose]

Apparently there was agreement to hide this kind of information, and that's
worse than the original behavior that was acted on. Who will be next? For what
reason?  I am not questioning the decision, at least we voted for our delegates,
so I have to respect that decision even if I would disagree.  If you don't want
to communicate in public, then email committers separately, or create a private
ML for committers.

Matthias


On 7/23/20 12:39 AM, Barry Warsaw wrote:
> It’s a really difficult call.  Please accept that everyone on the PSF Board, 
> SC, and WG are really trying to do their best.  I know you do Nathaniel, so 
> this is not meant to call you out personally, it’s just a general plea for 
> understanding.  This has been really difficult for everyone involved, often 
> in ways that are not visible publicly.
> 
> -Barry
> 
>> On Jul 22, 2020, at 13:54, Nathaniel Smith  wrote:
>>
>> Given that this is a response to behavior in public mailing list
>> posts, the lack of specificity feels off to me. Whatever this person
>> did is already public. What's being hidden isn't their behavior; it's
>> the conduct-wg/steering-council's reasoning for banning them. The
>> point of having a CoC is that everyone is on the same page and can be
>> confident about what behavior is unacceptable and acceptable, but it's
>> hard for them or others to learn from this, if you don't tell them or
>> us why they were banned...
>> ___
>> 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/22464N65TVY4UVECNZ3LL3YUD72S5C3C/
>> 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/DROOMERXTNHJ4K7I6A34HV2TEM22M7KI/
> 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/RXEXPH2A7ZUI4I7GQMO43AJAA256VU62/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Planning a hotfix Python 3.8.5

[Matthias Klose]

On 7/16/20 8:47 PM, Łukasz Langa wrote:
> Good call, Matthias. We will include it as long as it's merged before Monday 
> 8am CEST.

what exactly include?  Or just revert
https://github.com/python/cpython/commit/8912c182455de83e27d5c120639ec91b18247913
 on
the 3.8 branch?

> 
> - Ł
> 
> 
> 
>> On 16 Jul 2020, at 20:00, Matthias Klose  wrote:
>>
>> On 7/16/20 7:36 PM, Łukasz Langa wrote:
>>> Hey team,
>>> there are 3 security-related fixes in the 3.8 branch post 3.8.4, one with a 
>>> CVE, another with a pending CVE if I understood Steve correctly. I'd like 
>>> to release a hotfix 3.8.5 on Monday.
>>>
>>> Since this is a special security-focused release, it will be essentially 
>>> 3.8.4 + those three changes cherry-picked. That gives us enough confidence 
>>> about the release that we can skip a release candidate for it.
>>>
>>> If you have any other security-related changes you think belong in 3.8, 
>>> please merge them before Monday 8am CEST.
>>
>> what about https://bugs.python.org/issue41295 ?
>>
>> This is marked as a regression compared to 3.8.3.
>>
>> Matthias
> 
___
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/RNF2QSPV72BVL2ITNJB66KTN5NRWPSNE/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Planning a hotfix Python 3.8.5

[Matthias Klose]

On 7/16/20 7:36 PM, Łukasz Langa wrote:
> Hey team,
> there are 3 security-related fixes in the 3.8 branch post 3.8.4, one with a 
> CVE, another with a pending CVE if I understood Steve correctly. I'd like to 
> release a hotfix 3.8.5 on Monday.
> 
> Since this is a special security-focused release, it will be essentially 
> 3.8.4 + those three changes cherry-picked. That gives us enough confidence 
> about the release that we can skip a release candidate for it.
> 
> If you have any other security-related changes you think belong in 3.8, 
> please merge them before Monday 8am CEST.

what about https://bugs.python.org/issue41295 ?

This is marked as a regression compared to 3.8.3.

Matthias
___
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/OANDHUTOUCWMVMA52O4LOPPGK7GG2TOL/
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] OpenMandriva and Fedora abandoned Discourse for development discussions

[Matthias Klose]

On 27.02.19 22:11, Brett Cannon wrote:
> On Tue, Feb 26, 2019 at 3:40 PM Victor Stinner  wrote:
> 
>> Hi,
>>
>> Follow-up of the previous "Can we choose between mailing list and
>> discuss.python.org?" thread.
>>
>> Python isn't the first project who "experimented" Discourse to replace
>> mailing lists. It seems like Fedora and OpenMandriva are coming back
>> to mailing lists, at least for "development discussions":
>>
>>
>> https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/message/XQLY3MRJLC4CFMIRSYU5LRQSOPFF532X/
>>
> 
> It sounds like their overall team is much larger than ours based on the
> tone of that email (is that true?). We have also talked about having both
> Discourse and python-committers for announcements which would partially
> alleviate some of their concerns.
> 
> I also think it's telling that their decision to do this was done on IRC
> which is not a primary communication platform for all of us and suggests
> that it's possible the desires/needs/expectations of those participating
> are different.

well, #python-dev is another topic.  It now gets spammed by many bots, and human
chats are lost in the noise.  That used to be better.

Matthias
___
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] Date for the Language Summit?

[Matthias Klose]

On 21.02.19 11:38, Victor Stinner wrote:
> Hi,
> 
> What will be the date of the Language Summit? I had to organize myself
> very soon to get cheap flight and hotel, so I already booked
> everything for Pycon US :-)

+1

> Who will be allowed to attend? Will we have enough seats for all
> CPython core devs?
> 
> Mariatta, Lukasz: do you plan to invite people from other popular
> Python projects or other Python implementations?

I would like to see some presence of setuptools/pip maintainers. I think that
was missed at last PyCon by Conda developers, and distro packagers from RedHat
and Debian/Ubuntu.

Matthias
___
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 4.0 or Python 3.10?

[Matthias Klose]

On 25.09.2018 21:30, Yury Selivanov wrote:
> What's the current plan for what version of Python we release after 3.9?
> 
> The reason I'm asking this is because I frequently need to refer to
> *that version* of Python in the documentation, especially when I'm
> deprecating APIs or behavior.  Right now I'm saying "Python 4.0"
> implying that 4.0 will be released right after 3.9.
> 
> I've heard multiple opinions on this subject. One of them is that we
> should release 4.0 when we have a major new change, like removal of
> the GIL or introduction of a JIT compiler.  On the other hand, we have
> no estimate when we have such a change. We also don't want Python 4.0
> to be backwards incompatible with Python 3.0 (at least not at the
> scale of 2 vs 3).  So to me, it seems logical that we simply release
> Python 4.0 after Python 3.9.  After all, after 3.9 Python will be
> drastically different from 3.0 and from 2.7.  It sounds better. :)

why call it 4.0 when there are no significant changes?  Just calling it
4.something sends the wrong signal, that probably people try to skip 3.x and
keep going with 2.7 ...

> Finally, I'm not sure we need a new governance in place to make this
> decision or maybe we can make it now. That's why I'm posting this to
> python-committers to see if core devs already have a consensus on
> this.

sorry, for me that sounds like a non-decision.
___
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] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)

[Matthias Klose]

On 24.05.2018 20:09, Ned Deily wrote:
> On May 24, 2018, at 13:46, Larry Hastings  wrote:
>> On 05/24/2018 10:08 AM, Ned Deily wrote:
>>> If you (or anyone else) feels strongly enough about it, you should re-open 
>>> the issue now and make it as a "release blocker" and we should discuss the 
>>> implications and possible plans of action in the issue.
>>
>> About that.  According to the Python Dev Guide:
>> Whether a bug is a *release blocker* for the current release schedule is 
>> decided by the release manager. Triagers may recommend this priority and 
>> should add the release manager to the nosy list.
>>
>> https://devguide.python.org/triaging/#priority
>> Of course, a particular release manager (e.g. Ned here) can change the 
>> policy for their releases.  But by default, unless you're the release 
>> manager for release X, you should not mark issues as "Release Blocker" for 
>> release X.  This seems like a sensible policy to me, and effective 
>> immediately I'm going to hold to this policy for my releases (3.4 and 3.5).
> 
> I think we're reading the same words a bit differently.  There's no question 
> that the Release Manager makes the ultimate call whether an issue remains a 
> "Release Blocker" or not.  But it seems to me that the safest and most 
> reliable way to ensure that the Release Manager makes that decision is by 
> having a triager or submitter *provisionally* set the priority to "release 
> blocker".  It is then on the Release Manager's radar to accept or reject.  I 
> think that policy is totally in the spirit of the Dev Guide wording but I'm 
> fine with other release managers accepting differing interpretations for 
> their releases ;)
> 
> As for 3.6.x and 3.7.x, I would much prefer to have too many proposed 
> "release blocker" issues than to have too few.  And the sooner they are 
> reported, the better.

Ned's interpretation is the one I'm using for submitting such issues (maybe not
twelve hours before a final release). What other documented ways would you have
to get the attention of a release manager.

Having different interpretations depending on the release manager doesn't look
very practically.

Matthias
___
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] RELEASED] Python 3.4.7rc1 and Python 3.5.4rc1 are now available

[Matthias Klose]

On 25.07.2017 10:37, Larry Hastings wrote:
> And you can find Python 3.5.4rc1 here:
> 
>https://www.python.org/downloads/release/python-354rc1/
> 
> 
> Python 3.4.7 final and Python 3.5.4 final are both scheduled for release on
> August 6th, 2017.

the build of the documentation fails with at least the 3.5.4rc1.  It adds a new
build dependency (blurb), which is inconvenient to build on stable environments,
or when pip is not available. Please could you consider including the blurb
module itself in python for the stable branches?

The build of the docs then fails with:

make -C Doc html
make[1]: Entering directory '/home/packages/python/3.5/python3.5-3.5.4~rc1/Doc'
mkdir -p build
PYTHONPATH=/home/packages/python/3.5/python3.5-3.5.4~rc1/debian/blurb python3 -m
blurb merge -f build/NEWS
Traceback (most recent call last):
  File "/usr/lib/python3.5/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.5/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/home/packages/python/3.5/python3.5-3.5.4~rc1/debian/blurb/blurb.py",
line 1602, in 
main()
  File "/home/packages/python/3.5/python3.5-3.5.4~rc1/debian/blurb/blurb.py",
line 1562, in main
sys.exit(fn(*filtered_args, **kwargs))
  File "/home/packages/python/3.5/python3.5-3.5.4~rc1/debian/blurb/blurb.py",
line 970, in merge
versions = glob_versions()
  File "/home/packages/python/3.5/python3.5-3.5.4~rc1/debian/blurb/blurb.py",
line 284, in glob_versions
with pushd("Misc/NEWS.d"):
  File "/home/packages/python/3.5/python3.5-3.5.4~rc1/debian/blurb/blurb.py",
line 205, in __enter__
os.chdir(self.path)
FileNotFoundError: [Errno 2] No such file or directory: 'Misc/NEWS.d'
Makefile:42: recipe for target 'build' failed

there is no Doc/Misc/NEWS.d directory (neither a Misc/NEWS.d directory)
___
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] Should I delay 3.5.3 and 3.4.6 by two weeks?

[Matthias Klose]

On 19.12.2016 06:26, Larry Hastings wrote:
> 
> 
> Python 3.6.0 final just slipped by two weeks.  I scheduled 3.5.3 and 3.4.6 to
> ship about a month after 3.6.0 did, to "let the dust settle" around the
> release.  I expect a flood of adoption of 3.6, and people switching will find
> bugs, and maybe those bugs are in 3.5 or 3.4.  So it just seemed sensible.
> 
> 3.6 just slipped by two weeks.  So now there's less than two weeks between 
> 3.6.0
> final shipping and tagging the release canddiates for 3.5.3 and 3.4.6.  This
> isn't as much time as I'd like.
> 
> If I had total freedom to do as I liked, I'd slip my releases by two weeks to
> match 3.6.  But there might be people planning around 3.5.3 and 3.4.6--like
> Guido was waiting for 3.5.3 for something iirc.
> 
> So, if you have an opinion, please vote for one of these three options:
> 
>  * Don't slip 3.5.3. and 3.4.6.
>  * Slip 3.5.3 and 3.4.6 by two weeks to match 3.6.0.
>  * Slip 3.5.3 and 3.4.6 by a whole month, to give 3.6.0 the ability to
>slip again without us having to change the release.

I would appreciate a 3.5.3 release which doesn't slip, or which only slips by a
week, to be available before the Debian freeze.  Neither Debian nor Ubuntu ship
the 3.4 branch anymore, so for 3.4 I'm fine with any solution.

Matthias

___
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] Here's what's going into 3.5.2 final and 3.4.5 final

[Matthias Klose]

On 24.06.2016 11:14, Larry Hastings wrote:
> 
> 
> Heads up!  This is a courtesy reminder from your friendly 3.4 and 3.5 release
> manager.  Here's a list of all the changes since 3.5.2rc1 that are currently
> going into 3.5.2 final:
> 
>  * 155e665428c6 - Zachary: OpenSSL 1.0.2h build changes for Windows
>  * cae0b7ffeb9f - Benjamin: fix % in Doc/whatsnew/3.5.rst that confuses
>latex
>  * 783dfd77e4c1 - Terry Reed: allow non-ascii in idlelib/NEWS.txt
>  *  - Matthias: fix for test_ssl test_options on Ubuntu
> 
> 
> 3.4.5 final only has one change from 3.4.5rc1: the test_ssl test_options fix
> from Matthias.

won't this break on other platforms where SSL2 is still enabled?

___
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] The state of our copies of libffi (was: Redoing the C API?)

[Matthias Klose]

On 03.03.2016 21:58, Zachary Ware wrote:

On Thu, Mar 3, 2016 at 12:38 PM, Brett Cannon  wrote:

[...] the maintenance issue we have with ctypes (or at least that's
my hang-up with it). I think we still have not figured out what code we have
patched and so no one has been willing to update to a newer version of
libffi. I think Zachary looked into it and got some distance but never far
enough to feel comfortable with trying to update things.


Since I've been invoked, I'll try to explain our libffi situation as
far as I understand it.  This is just a history lesson, I don't really
have an opinion on what should be done with it.  I will opine that we
have some seriously old unmaintained code here, and the whole libffi
situation in cpython is far more complex than is ideal.

We actually have four separate copies of libffi:

Modules/_ctypes/libffi: This is a mostly-vanilla copy of libffi-3.1
(released 19May2014), lightly patched according to
Modules/_ctypes/libffi.diff.  This one is used for any non-OSX posix
build that doesn't use `--with-system-ffi`.  doko has done a pretty
good job keeping this one relatively up to date.


when trying to update these extra copies, I was always told that upstream was 
wrong/not ready, etc ... So I don't care that much about the copies.  The 
explicit diff was intended to document the explicit and wanted changes.


Now, the last libffi release 3.2.1 is more than a year old, and getting outdated 
for some architectures.  Upstream currently doesn't react, and the libffi copy 
within GCC is ahead with many changes.  My plan was to update libffi with a 3.3 
release when it comes out, but I don't know when this will happen.


Matthias

___
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] changing the python version on the 2.7 branch

[Matthias Klose]

On 04/02/2015 07:38 AM, Nick Coghlan wrote:
 On 2 April 2015 at 05:05, Matthias Klose d...@ubuntu.com wrote:
 We'll have the 2.7.10 release in the coming months. This will be the first
 release with a two digit subminor version number, so please could we prepare 
 for
 that early?  Feature tests in python are unfortunately way too often based on
 version comparisons.  Suggesting to push the following patch to the 2.7 
 branch.

 The patch also changes PY_RELEASE_LEVEL to beta quality.  Currently this 
 is a
 value which is not touched on the branches.
 
 I think this is a good idea, but I'd suggest using 2.7.10b0 as the
 interim version string, rather than 2.7.10-.

now checked, using the 2.7.10b0 string.

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

[python-committers] changing the python version on the 2.7 branch

[Matthias Klose]

We'll have the 2.7.10 release in the coming months. This will be the first
release with a two digit subminor version number, so please could we prepare for
that early?  Feature tests in python are unfortunately way too often based on
version comparisons.  Suggesting to push the following patch to the 2.7 branch.

The patch also changes PY_RELEASE_LEVEL to beta quality.  Currently this is a
value which is not touched on the branches.

Matthias


diff -r d96e714a Include/patchlevel.h
--- a/Include/patchlevel.h  Wed Apr 01 16:53:53 2015 +0300
+++ b/Include/patchlevel.h  Wed Apr 01 20:56:46 2015 +0200
@@ -22,12 +22,12 @@
 /*--start constants--*/
 #define PY_MAJOR_VERSION   2
 #define PY_MINOR_VERSION   7
-#define PY_MICRO_VERSION   9
-#define PY_RELEASE_LEVEL   PY_RELEASE_LEVEL_FINAL
+#define PY_MICRO_VERSION   10
+#define PY_RELEASE_LEVEL   PY_RELEASE_LEVEL_BETA
 #define PY_RELEASE_SERIAL  0

 /* Version as a string */
-#define PY_VERSION 2.7.9+
+#define PY_VERSION 2.7.10-
 /*--end constants--*/

 /* Subversion Revision number of this file (not of the repository). Empty
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

[python-committers] commit 93025:1c2c44313408 removed (at least) 2.7.9 NEWS entries

[Matthias Klose]

The commit 93025:1c2c44313408 removed almost all NEWS entries which were added
after the 2.7.8 release.  I didn't check for other files, but maybe somebody
more familiar with this commit/merge should have a look.

Matthias

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

Re: [python-committers] Status of the Derby, and request for another slip

[Matthias Klose]

Am 25.01.2014 14:09, schrieb Larry Hastings:
 I'd like to extend the Derby by two more weeks and add a fourth beta.

In the past I did like the way how accurate the releases were planned and didn't
slip at all, or only slip for a few days.

This may sound a bit selfish, but a few Ubuntu developers do run their own Derby
to use 3.4 as the default Python3 version for the next Ubuntu release in April,
so a timely release would be appreciated ;)

 Please vote for either continue the Derby (which also means slipping the
 schedule and adding a fourth beta) or stop the Derby.

that would be a biased -1 from my side

  Matthias

PS: For those interested, Ubuntu currently has the 3.4 beta as an alternative
version built.  I hope to have better results next week of what will break with
3.4 as the default python3 version.

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

Re: [python-committers] Updated schedule for Python 3.4

[Matthias Klose]

Am 16.01.2014 12:17, schrieb Kristján Valur Jónsson:
 This is such an obvious question that it probably has been raised before, but 
 anyway:
 Why not branch 3.4 earlier than release?  That is how big projects are 
 managed nowadays, you create a staging branch early.
 I'd suggest branching it off at b3.  There is no reason to keep all trunk 
 development frozen just because a particular version is in RC mode.

Big projects (like GCC) delay the branching as long as possible and only branch
when the trunk reaches release quality.  Branch maintenance eats developer
resources, and usually opening the trunk for new development distracts
developers from contributing to the release.  I do like the way how this is done
for Python (and GCC).

  Matthias

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

Re: [python-committers] 2.7.2 and 3.1.4 rc now

[Matthias Klose]

On 05/31/2011 07:19 AM, Martin v. Löwis wrote:
 Really??? I have some changes that I need to commit to 2.7 that do need
 to go into 2.7.2. So how are you going to manage these?

 I rather recommend that the 2.7 branch is frozen until the final
 release, and any changes are only merged afterwards.

 This is a mess.

two more questions:

 - How do I follow the what will become the release branch?
   In the past, you could just do an svn update on the branch
   at any time, but now this is different for development and
   freeze mode.

 - What do the buildd's test in freeze mode?  It would be bad
   to only test the branch, which doesn't see any changes.

Thanks, Matthias
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] updating libffi to 3.0.9?

[Matthias Klose]

On 24.02.2010 16:35, Ronald Oussoren wrote:


On Wednesday, February 24, 2010, at 08:20AM, Thomas 
Hellerthel...@ctypes.org  wrote:

Matthias Klose schrieb:

I would like to update the internal copy of libffi from the 3.0.5 release to
3.0.9 (plus an ARM specific patch checked in after the 3.0.9 release).  Is this
ok for the trunk and the py3kbranch?  I only can check linux targets and watch
the buildds, so I would like to ask for tests on other targets.


Obviously I don't do a good job maintaining the 'Python libffi fork', so
I have nothing against you or other people doing my work ;-).


well, I'm always buildig with --with-system-libffi for packaging, but I would 
like to have consistent test results on the buildds, which are not able to 
provide custom configure flags.


I now committed the update to the trunk; opened issue #8142 for further 
comments/changes.


I didn't touch the Modules/_ctypes/libffi_* directories, these maybe need 
updates/removals.


Proposed some changes from the libffi.diff file at 
http://gcc.gnu.org/ml/java-patches/2010-q1/msg00057.html



On the other hand:
Things have changed since the first inclusion of ctypes into the Python
distribution.  There were no 'official' libffi releases at that time;
now there are regular releases.  Should the Python distribution be changed
to use the system libffi by default - the '--with-system-ffi' configure option?
Is a system libffi library available on OS X?  On other systems?
The windows fork must probably stay...


OSX has a system libffi on OSX 10.5 or later. The binary installers cannot use 
that because libffi is not present on 10.4, and I'm also not 100% sure that 
libffi on 10.5 is fully binary compatible with that on 10.6.




The libffi subdirectories for testsuite, doc and man are currently not checked
in. Should these be kept out, or should the complete libffi release be checked 
in?


Depends on the answer to your first question, of course.  The libffi testsuite 
requires
dejagnus.  I know there once was a Python script, written by Ronald Ossouren, 
which
was able to execute the tests.


I have a testrunner in pyobjc that is able to run the libffi tests without 
dejagnu. I'm willing to contribute that to python.


I did check in the plain libffi 3.0.9 release, please could you add these 
changes to the trunk, and to the libffi.diff patch.


  Matthias
___
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

[Matthias Klose]

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
___
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

[Matthias Klose]

On 13.09.2009 18:07, Gregory P. Smith wrote:

On Sun, Sep 13, 2009 at 8:54 AM, Matthias Klosed...@debian.org  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:


another idea: have a pre-commit hook, which rejects modifications to this file
to entries for a released version, which can be overwritten by some keyword in 
the commit message.


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

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

[Matthias Klose]

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.

  Matthias
___
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?

[Matthias Klose]

Guido van Rossum schrieb:
 On Mon, Jan 26, 2009 at 1:59 PM, Matthias Klose d...@ubuntu.com wrote:
 Guido van Rossum schrieb:
 On Mon, Jan 26, 2009 at 1:27 PM, Matthias Klose d...@ubuntu.com 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.

 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.
 
 I would agree with you if it was for stuff that matters to the runtime
 environment. But IMO this strict requirement doesn't make sense for
 documentation in micro-releases -- changes to the documentation don't
 matter for the runtime backwards compatibility. AFAIK we also don't
 block performance improvements in micro-releases (though you'd have to
 ask a release manager for the exact policy).
 
 Would it help if we started bundling the required version of sphinx with 
 Python?

yes, it definitely would help, including the dependencies needed by sphinx.

 In general I expect that you're not going to get a lot of help with
 this issue, since it sounds like typical business as usual in the
 weird and wonderful world that is Debian politics, and we have limited
 patience for that.

you may call it politics, I call it reproducabilty of the build with a set of
requirements. the limitation on runtime backwards compatibility could allow
changes of the test environment as well, which might introduce noise in the
testsuite, having to investigate about a regression in the runtime or the
testsuite. I do see your point, but from the Debian point of view I do disagree.

 We're all volunteers here too, and we're not really
 looking for more work. If Debian wants to ship with an outdated
 version of Python, it is free to do so.

your conclusion is wrong. Debian does want to ship with the most recent Python
version released before a Debian freeze.

  Matthias

 --Guido
 
  Matthias

 I suspect few people here understand the
 (apparently largely political) ins and outs of the rules that guard
 inclusion into Debian -- I certainly don't, and I don't have the time
 to become an expert in them. So rather than trying to explain the
 rules to us, could you make a specific suggestion of something we
 could *do* to fix your problem?
 please see the proposals above. I'm not sure about the best approach how 
 to make
 backporting to the branch as easy as possible.

  Matthias

 --Guido

 On Sun, Jan 25, 2009 at 5:40 AM, Matthias Klose d...@ubuntu.com wrote:
 Hi,

 the requirement to build the documentation using a sphinx version from 
 the trunk
 was merged to at least the 2.6 branch. This is clearly not a bug fix. Is 
 it
 really necessary to rely on a trunk/unreleased version? Would it be 
 possible to
 revert this change?

 Background: The Debian distribution requires distribution of files which 
 can be
 edited in the preferred format, which excludes generated documentation. 
 I can
 pre-build the 2.6 documentation, and then include it in the so called 
 contrib
 section of the archive, but I would like to see it available in the 
 main
 section. Including a copy

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

[Matthias Klose]

Hi,

the requirement to build the documentation using a sphinx version from the trunk
was merged to at least the 2.6 branch. This is clearly not a bug fix. Is it
really necessary to rely on a trunk/unreleased version? Would it be possible to
revert this change?

Background: The Debian distribution requires distribution of files which can be
edited in the preferred format, which excludes generated documentation. I can
pre-build the 2.6 documentation, and then include it in the so called contrib
section of the archive, but I would like to see it available in the main
section. Including a copy of the sphinx trunk in the python package uploaded to
the distribution would be a hack around this (it is unlikely that the sphinx
trunk version will be available in Debian).

For python-2.5, Debian was not able to put the docs in the main section,
because a build tool with (in the eyes of Debian) non-free license was used to
build the docs. It is nice that this is fixed now, but for now one reason is
exchanged by another one why we cannot move the docs to Debian's main section
of the archive.

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