[python-committers] Roundup to GitHub Issues migration

[Ezio Melotti]

As you might know, PEP 581 (Using GitHub Issues for CPython) has been
approved.  I've been working with Ewa, Ee, the Working Group, the
Steering Council, and the GitHub folks to make this happen, and the SC
encouraged me to give you all a quick update.

This effort is being tracked at
<https://github.com/psf/gh-migration/projects/1>: this board reflects
the current status of the project.  The PEPs (including PEP 588 --
GitHub Issues Migration Plan) haven't been updated yet and might
contain outdated information, so please refer to the psf/gh-migration
repo for the latest updates.

During the next phase I will work with the WG to sort out all the
major issues that we might encounter, and then I will once again reach
out to you to gather feedback from the wider audience that follows
these mailing lists.

Best Regards,
Ezio Melotti
___
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/QQT7DOKTBKZRFLT6GUJLNQOC3YDLBSLU/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] PEP 595: Improving bugs.python.org

[Ezio Melotti]

Hello,
Berker and I have been working on a PEP that suggests we keep using
and improving bugs.python.org and Roundup instead of switching to
GitHub Issues as proposed by PEP 581.

The PEP covers:
* What are the advantages of Roundup over GitHub issues;
* What features are missing in Roundup and how can we add them;
* Issues with PEP 581;
* Issues with the migration plan proposed by PEP 588;

The rendered version of PEP 595 is available at
https://www.python.org/dev/peps/pep-0595/

For reference, you can consult PEP 581 and 588 at
https://www.python.org/dev/peps/pep-0581/ and
https://www.python.org/dev/peps/pep-0588/

The full text of the PEP is include below.  We are planning to update
the PEP to include the feedback we receive and to update the status of
features as we implement them (we also have a Google Summer of Code
students working on it).

Best Regards,
Ezio Melotti



PEP: 595
Title: Improving bugs.python.org
Author: Ezio Melotti , Berker Peksag

Status: Draft
Type: Process
Content-Type: text/x-rst
Created: 12-May-2019


Abstract


This PEP proposes a list of improvements to make bugs.python.org
more usable for contributors and core developers.  This PEP also
discusses why remaining on Roundup should be preferred over
switching to GitHub Issues, as proposed by :pep:`581`.


Motivation
==

On May 14th, 2019 :pep:`581` has been accepted [#]_ without much
public discussion and without a clear consensus [#]_.  The PEP
contains factual errors and doesn't address some of the
issues that the migration to GitHub Issues might present.

Given the scope of the migration, the amount of work required,
and how it will negatively affect the workflow during the
transition phase, this decision should be re-evaluated.


Roundup advantages over GitHub Issues
=

This section discusses reasons why Roundup should be preferred
over GitHub Issues and Roundup features that are not available
on GitHub Issues.

* **Roundup is the status quo.**  Roundup has been an integral
  part of the CPython workflow for years.  It is a stable product
  that has been tested and customized to adapt to our needs as the
  workflow evolved.

  It is possible to gradually improve it and avoid the disruption
  that a switch to a different system would inevitabily bring to
  the workflow.

* **Open-source and Python powered.**  Roundup is an open-source
  project and is written in Python.  By using it and supporting
  it, we also support the Python ecosystem.  Several features
  developed for bpo have also been ported to upstream Roundup
  over the years.

* **Fully customizable.**  Roundup can be (and has been) fully
  customized to fit our needs.

* **Finer-grained access control.**  Roundup allows the creation
  of different roles with different permissions (e.g. create,
  view, edit, etc.) for each individual property, and users can
  have multiple roles.

* **Flexible UI.**  While Roundup UI might look dated, it is
  convenient and flexible.

  For example, on the issue page, each field (e.g. title, type,
  versions, status, linked files and PRs, etc.) have appropriate
  UI elements (input boxes, dropdowns, tables, etc.) that are
  easy to set and also provide a convenient way to get info about
  the issue at a glance.  The number of fields, their values, and
  the UI element they use is also fully customizable.
  GitHub only provides labels.

  The issue list page presents the issues in a compact and easy
  to read table with separate columns for different fields.  For
  comparison, Roundup lists 50 issues in a screen, whereas GitHub
  takes two screens to shows 25 issues.

* **Advanced search.**  Roundup provides an accurate way to search
  and filter by using any combination of issue fields.
  It is also possible to customize the number of results and the
  fields displayed in the table, and the sorting and grouping
  (up to two levels).

  bpo also provides predefined summaries (e.g. "Created by you",
  "Assigned to you", etc.) and allows the creation of custom
  search queries that can be conveniently accessed from the sidebar.

* **Nosy list autocomplete.**  The nosy list has an autocomplete
  feature that suggests maintainers and experts.  The suggestions
  are automatically updated when the experts index [#]_ changes.

* **Dependencies and Superseders.** Roundup allows to specify
  dependencies that must be addressed before the current issues
  can be closed and a superseder issue to easily mark duplicates
  [#]_.  The list of dependencies can also be used to create
  meta-issues that references several other sub-issues [#]_.


Improving Roundup
=

This section lists some of the issues mentioned by :pep:`581`
and other desired features and discusses how they can be implemented
by improving Roundup and/or our instance.

* **REST API support.**  A REST API will make integration with other
  services and the development of new to

Re: [python-committers] [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

[Ezio Melotti]

Hello,

On Wed, May 15, 2019 at 5:18 PM Paul Moore  wrote:
>
> On Wed, 15 May 2019 at 15:56, Victor Stinner  wrote:
> >
> > Hi Paul,
> > Le mer. 15 mai 2019 à 11:40, Paul Moore  a écrit :
> > > Also, is there an archive of the discussions anywhere? The PEP says
> > > discussions happened on Zulip, but I don't follow that and I don't
> > > know where I can find an archived copy of the discussions.
> >
> > Well, the PEP has been discussed a lot at many places since May 2018.
>
> Thanks for all of these. I appreciate the time you took locating them
> for me. But I do have to say that I still can't really follow any
> useful "thread of discussion" - it all seems very fragmented, and it's
> difficult to see the progress towards consensus. Maybe that's just
> because I'm too used to mailing lists :-)
>

I share the same concerns:
1) the discussion was fragmented between
zulip/discuss/github/python-dev/python-committers/sprints/pycons and
very difficult to follow, even for interested people (Victor already
posted several links but missed a few others);
2) the progress toward consensus was not clear and the approval came
somewhat unexpectedly (it was mentioned a couple of weeks ago on
https://mail.python.org/pipermail/python-committers/2019-April/006705.html
and AFAICT no further discussion took place in public forums since
then);

In addition:
1) the PEP contains several factual errors.  I pointed this out during
the core-sprints last year and more recently Berker pointed out some
on GitHub: https://github.com/python/peps/pull/1013 ;
2) the "discussions-to" header of the PEP points to the zulip stream.
The stream has not been active for 6 months (it got a few new messages
today, the previous activity was in Dec 2018);
3) most of the discussions linked by Victor happened last year.
Unless I missed some, the only discussions happened this year are the
two on Discuss from February (with 3 messages each from a total of 5
authors), and the python-dev thread from March (with 12 messages from
7 authors).  One of the two Discuss threads was a inquiry about the
process (https://discuss.python.org/t/move-pep-581-discussion/873);
4) Berker is/was writing a competing PEP, in order to address the
problems of PEP 581 more effectively since his comments on GitHub
haven't been addressed;
5) next week a student is supposed to start working for the PSF on
b.p.o and Roundup as part of Google Summer of Code
(http://python-gsoc.org/psf_ideas.html);
6) PEP 8016 says "The council should look for ways to use these powers
as little as possible. Instead of voting, it's better to seek
consensus. Instead of ruling on individual PEPs, it's better to define
a standard process for PEP decision making.";

To summarize, I feel the approval of this PEP is premature and that
consensus was reached in a way that wasn't very transparent, without
considering some of the concerns.
(This might also be a symptom of a wider problem caused by the
fragmentation of the discussions between the old MLs, discuss, zulip,
IRC, GitHub PRs and issues, and IRL meetings, but this is a separate
topic.)

Best Regards,
Ezio Melotti




> > The PEP 581 has been (first?) discussed at the Language Summit which
> > was part of Pycon US 2018 (May 2018).
>
> Was that written up, or is it all just from people's memories by now?
>
> > https://github.com/python/peps/pull/681/
>
> Ah - I don't really follow this sort of PR discussion, as the github
> emails don't tend to have sufficient context on what's being said, so
> I (mostly) gave up a long time ago. Also, I tend to assume that
> discussions on PRs are mostly about details of wording, and
> substantive changes will be dealt with in a wider forum. I wonder if I
> should be following PRs on the PEPs repository more closely...?
>
> > Multiple threads on Discourse:
> >
> > https://discuss.python.org/t/move-pep-581-discussion/873
> > https://discuss.python.org/t/pep-581-using-github-issues/535
> > https://discuss.python.org/t/what-are-next-steps-for-pep-581/864
> > https://discuss.python.org/t/pep-process-after-pep-8016/558/4
> >
> > Thread on python-dev:
> >
> > https://mail.python.org/pipermail/python-dev/2019-March/156626.html
> >
> > Threads on python-committers:
> >
> > https://mail.python.org/pipermail/python-committers/2018-May/005428.html
> > https://mail.python.org/pipermail/python-committers/2018-June/005506.html
> > https://mail.python.org/pipermail/python-committers/2018-July/005657.html
>
> I saw these, but didn't get much of a sense of progress towards
> agreement. Again, maybe just because they were lots of fragmented
> threads and locations.
>
> > Discussion on Zulip Chat:
> >
> > https://python.zulipchat.com/#narrow/stream

Re: [python-committers] Steering Council Update for April 2019

[Ezio Melotti]

On Sun, Apr 28, 2019 at 11:58 PM Guido van Rossum  wrote:
>
> On Sun, Apr 28, 2019 at 2:05 PM Ezio Melotti  wrote:
>>
>> On Sat, Apr 27, 2019 at 10:44 PM Guido van Rossum  wrote:
>> >
>> > On Sat, Apr 27, 2019 at 11:10 AM Victor Stinner  
>> > wrote:
>> >>
>> >> Would it be possible to discuss these PEPs on python-dev? Or is it a 
>> >> deliberate choice to not let non core dev to be involved in the 
>> >> discussion?
>> >
>> >
>> > It was not a deliberate choice by the Steering Council. I remind you that 
>> > this is always going to remain controversial. I have one request: please 
>> > don't start a vote or poll.
>>
>> Do you mean that the decision to switch to GitHub Issues has already
>> been taken (so vote/polls would be pointless), or is the discussion
>> still open?
>
>
> The latter. I meant to warn Victor not to start a poll before prematurely -- 
> we should first attempt to find (rough) consensus.
>

Thanks for clarifying.
___
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] Steering Council Update for April 2019

[Ezio Melotti]

On Sat, Apr 27, 2019 at 10:44 PM Guido van Rossum  wrote:
>
> On Sat, Apr 27, 2019 at 11:10 AM Victor Stinner  wrote:
>>
>> Would it be possible to discuss these PEPs on python-dev? Or is it a 
>> deliberate choice to not let non core dev to be involved in the discussion?
>
>
> It was not a deliberate choice by the Steering Council. I remind you that 
> this is always going to remain controversial. I have one request: please 
> don't start a vote or poll.
>

Do you mean that the decision to switch to GitHub Issues has already
been taken (so vote/polls would be pointless), or is the discussion
still open?
___
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] Steering Council Update for April 2019

[Ezio Melotti]

On Fri, Apr 26, 2019 at 7:18 PM Berker Peksağ  wrote:
>
> On Fri, Apr 26, 2019 at 5:55 PM Guido van Rossum  wrote:
> > - **Issue tracker:** We've discussed PEP 581, "Using GitHub Issues for
> >   CPython" by Mariatta Wijaya.  We're in favor of this move, and feel
> >   that the transition should be professionally planned and executed.
> >   In collaboration with the PSF we're exploring ideas on how to do
> >   that (using the successful roll-out of the new Warehouse
> >   infrastructure for PyPI as a model).
>
> I don't think there was a consensus on switching to GitHub Issues last
> time it was discussed. The most recent discussion about PEP 581 only
> has 12 messages. I think the council is making a premature decision
> here.
>

Recently Ernest migrated the tracker on a new machine, and he has been
working on setting up a new test tracker.
On the Roundup side, they have been working on porting Roundup to
Python 3 and integrating the REST API we developed a few years ago
with a GSoC student.
I also submitted another GSoC proposal for this year with the goal of
updating Roundup on b.p.o and writing tools that take advantage of the
REST API (http://python-gsoc.org/psf_ideas.html).
I was planning to write to python-committers and ask what features do
we want to develop first, but I was already coordinating between
Ernest, the Roundup folks, and GSoC admin/students so I was waiting to
make sure things were viable before involving python-committers.  On
May 9 we will know for sure if we got a student, but things are
currently looking good.

I'm also aware of PEP 581 and the fact that we might eventually decide
to abandon Roundup, however this work will still benefit Roundup and
its users regardless of what we end up doing -- that's why I went
ahead and submitted the proposal without discussing it with
python-committers first.

> I'm strongly against using GitHub Issues. I will change my mind once I
> see a sign that GitHub is actually listening to our feedback. We can't
> even get them to make the use of # and GH- in the commit title
> configurable (https://github.com/maintainers/early-access-feedback/issues/77)
> and have the ability to automatically strip intermediate commit
> messages from the commit message body
> (https://github.com/maintainers/early-access-feedback/issues/153) The
> only time I got a response from them was this:
> https://github.com/python/miss-islington/issues/16#issuecomment-396095622
>
> I volunteered to maintain our Roundup instance a while ago and already
> fixed some bugs: https://hg.python.org/tracker/python-dev/ I've also
> submit patches to improve UX and fix issues. I'd list list them here
> but I can't reach out to http://psf.upfronthosting.co.za/roundup/ at
> the moment. I hope the problem with the hosting is temporary because I
> have several non-trivial patches there.
>

The meta tracker at upfronthosting is gone for good, but nothing is
lost, we have backups and can retrieve the patches if we need them.

Best Regards,
Ezio Melotti

> --Berker
___
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] Comments on moving issues to GitHub

[Ezio Melotti]

ecently suggested a solution that
still needs to be tested.

> - making the issue tracker usable on mobile devices

The Roundup team has already some working prototype.

> - ability to edit the description for issues that evolve over time, not just 
> the title
> - improved editing support for comments (both in initial formatting, and in 
> being able to correct errors)

Comment editing shouldn't be too difficult to implement.  (For
"description", do you mean the first/initial message/comment?)

> - REST API access to tracker data

The code has been written, it needs to be merged and tested on a live
instance.  (I'm particularly concerned about security here, since it's
a whole new API that could expose new vulnerabilities, and even though
care has been taken when the code was written, I'm no security expert
and I would like if someone tried to break it in ways I'm not yet
aware of).

> - simplifying account creation (especially for folks that already have GitHub 
> accounts)

Adding GitHub login to b.p.o should be doable too.

> - rationalising the metadata fields by asking which ones actually see 
> significant use

These have been discussed and changed several times over the years.
With the REST API it will be easier to gather better usage stats.
FWIW there are some notes and ideas about it at
https://wiki.python.org/moin/TrackerDevelopmentPlanning#workflow and
https://wiki.python.org/moin/DesiredTrackerFeatures

> 

> But as of right now we have zero people supporting b.p.o (and GitHub has one
> with Mariatta which puts GH ahead in my book). Because of this, in my
> opinion this discussion shouldn't include b.p.o as an option until those
> volunteers materialize. We can argue GitHub versus GitLab versus some other
> issue tracker (open or closed source, self-hosted or service-hosted I
> personally don't care; heck write it from scratch like Warehouse if that's
> what it takes), but unless we get some people to step forward to help with
> b.p.o then I personally consider it our temporary solution until we figure
> out where we're going next with b.p.o and not a viable option in this
> discussion.
>

Even if the volunteers don't materialize (and I dematerialize), we
still have to determine if the cost of keep using b.p.o as is, is
greater than the cost of moving everything to a new system.

Best Regards,
Ezio Melotti
___
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] Let's give commit privileges to Nathaniel J. Smith

[Ezio Melotti]

+1

On Thu, Jan 25, 2018 at 12:23 AM, Yury Selivanov
 wrote:
> Hi,
>
> I want to propose granting commit privileges to Nathaniel J. Smith.
> He's interested in the idea of becoming a core developer, and given
> the quality of his contributionsI think he won't need any extensive
> mentoring (although I'll be happy to assist Nathaniel in the
> beginning).
>
> Nathaniel has been a prolific PEP author:
>
> * Single-authored: PEP 465 Matrix Multiplication (accepted), PEP 521,
> PEP 533, PEP 568;
>
> * Co-authored: PEP 513 (active), PEP 516, PEP 517 (accepted), PEP 518
> (accepted), PEP 522.
>
> * Many PEPs mention his name in acknowledgements.
>
> He also has a few sufficiently complex patches committed, some of
> which touch complex areas like ceval loop and signals handling:
>
> * bpo-32591: Add native coroutine origin tracking
> * bpo-30579: Allow TracebackType creation and tb_next mutation from Python
> * bpo-30050: Allow disabling full buffer warnings in signal.set_wakeup_fd
> * bpo-30039: Don't run signal handlers while resuming a yield from stack
> * bpo-30038: fix race condition in signal delivery + wakeup fd
> * etc
>
> He's been very active on python-dev, python-ideas, bugs.python.org and
> github. Here's an example where Nathaniel's research helped us to make
> a right decision to fix a broken socket object API:
> https://bugs.python.org/msg308450.
>
> He helped me quite a bit with the design of PEP 550 and PEP 567, and
> he's doing some interesting work in the async/await area.
>
> So... let's make it happen? :)
>
> Yury
> ___
> 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] Julien Palard not seen as a core dev on the bug tracker

[Ezio Melotti]

Done as well!

On Mon, Dec 18, 2017 at 3:47 PM, Victor Stinner
<victor.stin...@gmail.com> wrote:
> Oh, Julien told me that he doesn't have the bug triage permission
> neither. Would you mind to allow him to close bugs as well? :-)
>
> Victor
>
> 2017-12-18 14:57 GMT+01:00 Ezio Melotti <ezio.melo...@gmail.com>:
>> On Mon, Dec 18, 2017 at 12:01 PM, Victor Stinner
>> <victor.stin...@gmail.com> wrote:
>>> Hi,
>>>
>>> Julien Palard has been promoted as a core developer at December 8th:
>>> https://devguide.python.org/developers/#permissions-history
>>>
>>> But he is still not seen as a core dev on the bug tracker:
>>> https://bugs.python.org/user23063
>>>
>>> His nick name is "mdk". Can someone please fix his bpo account?
>>>
>>
>> Done, and welcome to the team Julien!
>>
>> Best Regards,
>> Ezio Melotti
>>
>>> Devguide: https://devguide.python.org/coredev/#issue-tracker
>>>
>>> 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/

Re: [python-committers] Julien Palard not seen as a core dev on the bug tracker

[Ezio Melotti]

On Mon, Dec 18, 2017 at 12:01 PM, Victor Stinner
<victor.stin...@gmail.com> wrote:
> Hi,
>
> Julien Palard has been promoted as a core developer at December 8th:
> https://devguide.python.org/developers/#permissions-history
>
> But he is still not seen as a core dev on the bug tracker:
> https://bugs.python.org/user23063
>
> His nick name is "mdk". Can someone please fix his bpo account?
>

Done, and welcome to the team Julien!

Best Regards,
Ezio Melotti

> Devguide: https://devguide.python.org/coredev/#issue-tracker
>
> 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/

Re: [python-committers] Requirements to get the "bug triage" permission?

[Ezio Melotti]

On Fri, Dec 8, 2017 at 5:32 PM, Victor Stinner <victor.stin...@gmail.com> wrote:
> 2017-12-08 17:19 GMT+01:00 Ezio Melotti <ezio.melo...@gmail.com>:
>>> Aha. Maybe we need some tooling, like statistics on contributions to the
>>> bug tracker, just to detect earlier active "bug triagers"?
>>>
>>
>> This can be done (e.g. the famous highscores page we have been talking 
>> about).
>
> My opinion on such statistics is that they must not be public. I don't
> want to reward the highest number of contributions. As I wrote in the
> process documentation, what matters is the quality and kind of the
> contributions, and also the commitment.
>
> But a private tool, only accessible to core dev for example, would
> easy the work of identifying active contributors.
>

It doesn't necessarily have to be based solely on number of
contribution.  Twisted uses a formula that rewards different kind of
contributions differently.  In theory there could also be different
leaderboards based on number of commits, lines of code, PR submitted,
reviews done, PR/issues closed, etc.  I trust that if we ever get
around implementing this, the contributors won't abuse it, and to
prevent that we can simply add a line saying something like "The
number of contribution doesn't take into account the quality or the
complexity of the contributions.".
I don't think it should be private, as one of its main purposes is to
recognize the work of the contributors, not only by us, but also by
themselves and other contributors.

>
>> There are however other triagers that just go through the issues and
>> adjust fields or comment, even if they have no intention of working on
>> the issue itself.
>> While it's technically true that there might be people that want to
>> triage but not contribute code, most of them do contribute, and triage
>> while going through the issues.
>
> Hum, as Ned Deily wrote, some people don't want to become core
> developers and are fine to contribute as regular contributors. I
> should clarify this in the document.
>
> By the way, since the migration to Git and GitHub, contributing
> without being a core dev became simpler IMHO.
>
>
>>> My hope is that many contributors are potential core developers but were
>>> stuck somewhere, and failed to get the right documentation or mentor to
>>> unblock them.
>>>
>>
>> This is a good point, but indeed, how many are contributing with the
>> goal and hope of becoming core devs?  How many are contributing
>> because they like the project, and would be happy to become core devs?
>>  How many are just scratching a itch but otherwise have no desire to
>> contribute to other aspects of the project?
>> Finding an answer to these questions might help understanding where
>> are the problems that need to be addressed.
>
> Ow, these are tricky questions! Maybe a poll sent to contributors, or
> to python-dev, would help?
>
> 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/

Re: [python-committers] Requirements to get the "bug triage" permission?

[Ezio Melotti]

On Thu, Dec 7, 2017 at 11:20 PM, Victor Stinner
<victor.stin...@gmail.com> wrote:
> (I tried to answer to all replies. Since I chose to reply in a single
> email, so I chose to reply to own initial email.)
>
> Hi,
>
> It seems like I didn't express my ideas with the right words and so
> misguided the discussion. I'm sorry about that. I wrote a full
> "promotion process" document where I tried to pick better words. For
> example, I replaced "award" with "responsibility" ;-)
>
> My email:
> https://mail.python.org/pipermail/python-committers/2017-December/005000.html
>
> 2017-11-20 19:12 GMT+01:00 R. David Murray <rdmur...@bitdance.com>:
>>> Did it happen in the past that we removed the bug triage permission
>>> to someone who abused this power?
>>
>> Only once that I'm aware of.
>
> IMHO it's ok remove permissions if we have to. Instead of making such
> event abnormal, I proposed a training period of one month when the
> permission can be reverted anytime if the contributor misbehaves while
> being told to change their behaviour.
>
> I hope that the removal of the permission after the training period will
> be exceptional. I also added the need to get a mentor to reduce the risk
> even further. The mentor is not responsible of the behaviour of the
> contributor, but is here is guide and help the contributor.
>

While most of these suggestions seem to help define the process, ISTM
they are also making it more bureaucratic.

>
> R. David Murray <rdmur...@bitdance.com>:
>>> Maybe we can give some guide lines on how to behave on the bug
>>> tracker?
>>
>> Enhance the bug triage section of the devguide, by all means :)
>
> To not forget, I created an issue in the devguide project!
> https://github.com/python/devguide/issues/308
>
>
> 2017-11-20 19:59 GMT+01:00 Ezio Melotti <ezio.melo...@gmail.com>:
>> but we don't have a well defined procedure and sometimes people keep
>> contributing for weeks before someone realizes they could become
>> triagers.
>
> Aha. Maybe we need some tooling, like statistics on contributions to the
> bug tracker, just to detect earlier active "bug triagers"?
>

This can be done (e.g. the famous highscores page we have been talking about).

> On Git, it's simpler, there already many tools computing statistics on
> the number of commits.
>
>
> 2017-12-06 18:45 GMT+01:00 Ezio Melotti <ezio.melo...@gmail.com>:
>> Depends on what you exactly mean with "award".  Contributors might
>> want to be able to edit more fields on the tracker, and the triage bit
>> allows them to do it.  This is beneficial for both the contributor and
>> the other triagers, since they have one more helping hand. (...)
>
> Here is where I failed the most to explain myself.
>
> If you consider that the long term goal is to train contributors to
> become core developers, bug triage is just one of the task and
> responsibility of a core developer.  To exagerate, you cannot become a
> core developer if you don't know how to triage bugs properly.
>
> In my point of view, giving the bug triage permission is first a new
> responsibility, not a permission or an "award". The contributor becomes
> able to make bigger mistakes and so must be careful. The idea is to give
> permissions and responsibilities step by step to contributors, rather
> than giving them as once as the "core developer package".
>

With this I agree, and as I mentioned below, I think all core devs
should have the triage bit and know how to use it.

> To come back to bug triage itself, obviously, the permission gives
> access to features not available to regular contributors, and so allows
> to better triage bugs.
>
>
> 2017-12-06 19:45 GMT+01:00 Ned Deily <n...@python.org>:
>> In general, I agree with David's and Ezio's comments, in particular
>> the idea that "bug triage" should not be an "award" nor a necessary
>> first step towards being a committer.  I think the skills necessary to
>> be a good bug triager are not the same as being a good core developer.
>> While the skill sets and experience level needed can overlap, I think
>> we should consider the two roles as separate "career paths".  In other
>> words, some people would do a fine job as triager without wanting to
>> be a core developer or contributing their own code patches, and that's
>> fine.
>
> I agree and like the idea of contributors who enjoy bug triage without
> wanting to contribute to the code.
>
> But technically, when I say "bug triage permission", I understand at
> least being able to clos

Re: [python-committers] Statistics: growth of core dev number vs growth of the code size/complexity

[Ezio Melotti]

On Thu, Dec 7, 2017 at 8:43 PM, Brett Cannon <br...@python.org> wrote:
>
>
> On Wed, 6 Dec 2017 at 15:17 Victor Stinner <victor.stin...@gmail.com> wrote:
>>
>> Hi,
>>
>> I wrote a quick & dirty parser to compute statistics on *new* CPython
>> core developer per year using the following page as data:
>> https://devguide.python.org/developers/
>>
>> 2007: 15
>> 2008: 19
>> 2009: 11
>> 2010: 20
>> 2011: 12
>> 2012: 9
>> 2013: 4
>> 2014: 10
>> 2015: 2
>> 2016: 5
>> 2017: 2
>>
>> Compare these numbers to Stéphane Wirtel's statistics on pull requests:
>>https://speakerdeck.com/matrixise/cpython-loves-your-pull-requests
>>
>> => Number of active core developerson on GitHub pull requests: 27
>> (stats from February 2017 to October 2017)
>> (I'm not sure of the meaning of this number, it's the number of core
>> developer who authored pull requests, I don't think that it counts
>> core developers who only made reviews.)
>>
>> If you look at the size of the source code, it's still growing
>> constanly since 1990:
>> https://www.openhub.net/p/python/
>>
>> 2007: around 783k lines
>> 2010: around 683k lines
>> 2013: around 800k lines
>> 2015: around 875k lines
>> 2017: around 973k lines
>>
>> The number of bugs is also constanly growing. Statistics on bugs since
>> 2011:
>> https://bugs.python.org/issue?@template=stats
>>
>> 2011: around 2500 open issues
>> 2013: around 4000 open issues
>> 2015: around 5000 open issues
>> 2017: around 6200 open issues
>
>
> Do realize that open issues is a really misleading statistic as they include
> enhancement requests which we historically never close unless there's zero
> chance we will accept such a change.
>

Here is a breakdown:
2443 behavior
2124 enhancements
224 crash
170 compile error
125 resource usage
104 performance
44 security


>>
>>
>> The size of the CPython project is constantly growing as its
>> complexity (technical debt? what is this? :-)), but the growth of core
>> developers is slowing down.
>
>
> Well, you added code to speed up Unicode encoding/decoding, right? So it's
> just adding stuff to keep things performant as well as new things. It's just
> what happens when you're willing to improve things.
>
>>
>>
>> I do consider that we need more people to handle the growing number of
>> issues and pull requests, so the question is now how to find and
>> "hire" (sorry, promote) them ;-)
>>
>> Maybe we have a problem with mentoring. Maybe the CPython code base
>> became too hard to train newcomers? Maybe we are too conservative? I
>> don't know.
>
>
> I think it's partially a fact that Python's popularity has increased the
> pool size of contributors, so lots of people grabbing individual things.
> This leads to less of a chance to make sustained contributions. E.g. when I
> became a core dev it was because I was able to grab a new issue to work on
> that was easy at a very regular cadence, but I don't know if I could rectify
> that at this point.
>

I think it also has to do with the maturity of the project.

When I started I remember I wanted to fix some issue and when I ran
the whole test suite I had at least a dozen failing on my machine, so
I went and fix those as well.  But to fix those I needed to add more
stuff to test.support and to regrtest, and so I did.  Then those
changes needed to be documented, but the documentation was missing.
So I started improving the documentation and even after all that was
done there were still plenty of low hanging fruits on the bug tracker
or other issues to work on.  Then Python 3 came, and there was more
work to be done.

Nowadays the situation is much better, Python is more stable and
mature, and what's left is more difficult, obscure, or controversial.
There are still new modules and features being added and ISTM that
most of the new core devs are working on those (e.g.
asyncio/typing/etc), but otherwise finding new easy issues is becoming
increasingly more difficult.

Best Regards,
Ezio Melotti
___
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] RFC: Process to become a core developer

[Ezio Melotti]

On Thu, Dec 7, 2017 at 11:38 PM, Victor Stinner
<victor.stin...@gmail.com> wrote:
> 2017-12-07 19:21 GMT+01:00 Antoine Pitrou <anto...@python.org>:
>>> == Step 2: Bug Triage Permission ==
>>>
>>> Once a contributor becomes active enough, a core developer can propose
>>> to give the bug triage permission to the contributor.
>>
>> It sounds like you are not taking into account what was said by various
>> people during the previous discussion.
>
> I did, but I'm not sure that you (Antoine and others) understand
> properly my intent.
>
> Please see the reply that I just sent on the other "Requirements to
> get the "bug triage" permission?" thread.
>
>
>>> == Step 3: Getting a mentor ==
>>>
>>> Python project is big and has a long history. Contributors need a
>>> referrer to guide them in this wild and dangerous (!) project, and in
>>> the development workflow.
>>
>> Perhaps you are overdoing this? :-)
>
> Maybe, who knows? :-)
>
>
>>> Required mentor skills:
>>>
>>> * Be a core contributor.
>>> * Be available at least during one whole month.
>>> * Follow the contributor: must get an update at least once a week,
>>> especially if the contributor doesn't show up.
>>
>> I'm afraid these requirements may make the process actually harder than
>> it currently is.  What if there is no potential mentor available?  This
>> reminds of the Google Summer of Code...
>
> I would lie if I would say that being a mentor is a trivial task that
> doesn't take any time. But from what I hear around me, mentoring the
> *key* difference to train faster motivated contributors.
>

In my experience, contributors that get promoted to core devs are
usually already experienced, but they might not be familiar with all
the quirks of CPython development and they will likely have a few
CPython-specific questions.
When I became a core dev I don't remember having an official mentor. I
had several different questions (should I backport this to Python 2.3?
 how do I use svnmerge? how do I create a wide unicode debug build?
which rst role should I use to document X?) and always received a
timely reply from several different people, depending on who was
available and their main area of expertise (also note that there was
no devguide back then :).

In my opinion, the role of the mentor should boil down to:
1) be a reference for the new core dev and be available in case
everything else fails (e.g. if no one else answers a question);
2) be responsible for the mistakes the new core dev might make (e.g.
help fixing up a bad merge or a broken buildbot caused by the new core
dev).
The mentor shouldn't babysit the new core dev and be in the only point
of contact.

The new core dev should:
1) interact with the other core devs and the community in general;
2) reach to the mentor only when necessary (i.e. no one else replied,
something import/urgent/"personal").


For GSoC the situation is different:
1) GSoC students have to work on a specific project with specific
goals, requirements, and deadlines;
2) GSoC students are usually less experience and need to be followed,
guided, and sometimes pushed;
3) Given its breadth and maturity, CPython itself is not a
particularly good candidate for GSoC projects.

Best Regards,
Ezio Melotti

> A single people cannot be the mentor of too many contributors at the
> same time. The bootstrap is going to be hard :-(
>
>
> Oh, if you didn't see it yet, I strongly suggest to watch Mariatta
> Wijaya's talk about mentoring at the last Pycon US:
> https://www.youtube.com/watch?v=Wc1krFb5ifQ
>
> She explained that mentoring is also valuable for the mentor! It goes
> in both directions.
>
>
> Another option is the idea proposed in parenthesis, that contributors
> mentor them each other. I wouldn't count as the official required
> mentoring, but it would help anyway. I think that it is already
> happening right now on the core-mentorship mailing list, helping each
> other.
>
>
> In the past, I mentored Xavier De Gaye and Xiang Zhang during one
> month *after* they became core developers. Honestly, it took me less
> than one hour per week. Ok, maybe they are not the best examples of
> contributors, since they already had a good background. But I'm not
> less afraid of being a mentor ;-)
>
> The "Step 3: Getting a mentor" isn't the first step just after "Step
> 0: Newcomers". The expectation is that the contributor already knows
> enough about Python workflow and code, before getting a mentor.
>
> For steps before the step 3, there is already the core-mentorship
> mailing list. IMHO this list is working well as intended. People who
> r

Re: [python-committers] Requirements to get the "bug triage" permission?

[Ezio Melotti]

On Wed, Dec 6, 2017 at 6:11 PM, Victor Stinner <victor.stin...@gmail.com> wrote:
> Hi,
>
> Ok, thanks Ezio and David. I completed my list:
> https://github.com/vstinner/cpython_core_tutorial/blob/master/core_developer.rst#bug-tracker
>
> My initial question is to know if bug triage permission can be seen as
> a first "award" / "badge" to recognize that contributions of someone
> are useful. Contributions can only be made of code pull requests, or
> another "project" tightly coupled to CPython like the documentation,
> the development workflow, etc.
>
> My problem is now that the list of requirements is very long. It's
> like you should already practice triage for weeks before being seen as
> ready to get the triage power.
>
> So do you think that it's bad idea to use triage as an award? Or is it
> just a matter of adjusting requirements?
>

Depends on what you exactly mean with "award".
Contributors might want to be able to edit more fields on the tracker,
and the triage bit allows them to do it.  This is beneficial for both
the contributor and the other triagers, since they have one more
helping hand.  If the contributor knows what they are doing and they
are helpful, we can "award" them with the triager bit, but this award
shouldn't be given for unrelated accomplishments.
Becoming a triager is a step to becoming a committer: we bestow them
with some responsibility and trust, and if they do well, we can give
them even more with the committer bit.

Best Regards,
Ezio Melotti

> I have a few people in mind that I would like to give them triage
> permission, but I don't know that they contributed much to the bug
> tracker. I don't expect them to be active on the bug tracker neither.
>
> 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/

Re: [python-committers] Requirements to get the "bug triage" permission?

[Ezio Melotti]

On Mon, Nov 20, 2017 at 10:12 AM, R. David Murray <rdmur...@bitdance.com> wrote:
>
> On Mon, 20 Nov 2017 18:54:50 +0100, Victor Stinner <victor.stin...@gmail.com> 
> wrote:
> > I identified some active contributors and I would like to offer them
> > to get the "bug triage" permission. What's the requirements to give
> > such permissions to someone?
>
> Currently it is "someone with the power to do it decides to give it out".
> Should we have more detailed/conscious requirements?  Perhaps so.
>
> > IMHO the requirements are quite low:
> >
> > * at least one commit merged in Python
> > * signed the CLA
>
> I have never looked for either of these when giving out triage.  I can
> see that having signed the CLA is probably a good idea, but I see no
> reason to have getting a patch merged be a requirement.
>

Both those requirements shouldn't strictly be necessary (triaging
shouldn't be covered by the CLA), however people that are interested
in triaging often made previous contributions and signed the CLA
already.  I wouldn't be against requiring the CLA to be signed as a
requirement.

> > * be nice and respectful
> > * don't close a bug if it's not well understood to not "loose"
> > information (closed bugs are ignored in search by default, and hidden
> > from the main page).
>
> Personally my criteria is heavy on "be nice and respectful", coupled
> with observing that they have posted comments on issue that demonstrate
> an understanding of our code culture...specifically, commenting that a bug
> should be closed (and why) and I agree with them, and demonstrating an
> understanding of what python versions a bug applies to (enhancement
> versus bug fix, when to backport a bug fix and when not).
>
> How it generally works for me is that I think, "this person knows
> what they are talking about, they ought to be able to close this issue
> themselves instead of my having to do it for them".  Then I pull up a
> list of all the issues they are nosy on, and look at their comments to
> see if they are consistently polite and respectful, know what they are
> talking about, and explain their reasoning well.  If I don't see any
> red flags, I give them triage.
>

+1
A good triager must be familiar with our codebase, our bug tracker,
and our "code culture", in particular:
* being able to find (or remember) duplicate and related issues, link
them to each other, and closing the duplicates as necessary;
* being able to correctly select the versions affected by the issue,
the components, the stage, and other fields;
* being able to verify if the issue can be reproduced and if the
report is valid or not;
* being able to recognize commonly reported issues and link to the
appropriate FAQ or other existing issues/explanations;
* being able to identify and specify the next step, possibly
suggesting which files should be updated to fix the issue;
* being able to locate the commits that might have introduced the
issue, and the reason for the change;
* being able to leave meaningful opinions on the issue (e.g. whether
it should be addressed or closed and why);

It usually takes some time and a few contributions before people can
do these things, and by the time they do, they usually get noticed by
other core devs.
By that time, either they ask for more power themselves, or a core dev
asks them if they would like to become triagers, but we don't have a
well defined procedure and sometimes people keep contributing for
weeks before someone realizes they could become triagers.

To avoid this, we can either:
1) let contributors know that they could ask for more power if they
think they can handle it;
2) be more proactive and check regularly if there are contributors
deserving of more power;

Best Regards,
Ezio Melotti

> > Did it happen in the past that we removed the bug triage permission to
> > someone who abused this power?
>
> Only once that I'm aware of.
>
> > Maybe we can give some guide lines on how to behave on the bug tracker?
>
> Enhance the bug triage section of the devguide, by all means :)
>
> --David
___
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] What is a CPython core developer?

[Ezio Melotti]

On Wed, Oct 4, 2017 at 6:58 PM, Victor Stinner <victor.stin...@gmail.com>
wrote:

> 2017-09-22 18:48 GMT+02:00 Antoine Pitrou <anto...@python.org>:
> >> * Long term commitement. (...)
> >
> > Unfortunately we can't evaluate that in advance.  Even the person being
> > promoted often does not known whether they'll still be there in 5 or 10
> > years.  Hopefully that's on their horizon, but many factors can
> interfere.
>
> To be clear, I disagree with the "long term commitement", but I tried
> to summarize what I heard from other core developers. I think that it
> would be wrong to at least not mention it. If most core developers
> disagree with this requirement, we should remove it. If there is no
> consensus, I prefer to mention it *but* also explains that it's not
> strictly a "requirement", but more a "whish".
>

I think it really depends on the reason the developer has been given commit
privileges:
* generic work on the documentation, tests, or stdlib? several people can
take over if the dev disappears
* changed something specific in the language (e.g. import system, Unicode
representation)? some people can take over
* added new features to the language (e.g. typing, asyncio) or a new
module? few people can take over

IOW, the lower the bus factor, the higher are the expectations of long term
commitment.

In my case I used to do lot of generic work on CPython and when I became
less active other people took over with not many repercussions.  For more
specific areas (e.g. html.parser or Unicode) I still try to participate to
the discussions.  For the bug tracker I have to commit long-term because
other devs lack the time and/or knowledge required to maintain it.

Best Regards,
Ezio Melotti




> I will try to clarify expectations in term of time, evenings, weekends
> and holidays :-)
>
> > I, personally, can only think of a couple of cases where a person being
> > promoted core developer vanished a few months after that.  It's not a
> > big deal in the grand scheme of things, though it *is* frustrating to
> > spend your time mentoring and promoting someone (which also engages your
> > own responsability, since you're the one vouching that they'll be up to
> > the task) only to see that person produce little to no work as a core
> > developer.
>
> While it's sad, I don't think that we can prevent this. It's hard to
> "force" someone to work for free on a free software during nights and
> weekends.
>
> >> * Review patches and pull requests. While we don't require not expect
> >> newcomers to review, we expect that core developers dedicate a part of
> >> their time on reviews.
> >
> > Yes, I believe this is the most important part of being a core
> > developer.  What it means is that core developers care about the quality
> > of the whole code base (and also the non-code parts), not only their own
> > contributions to it.
>
> I completed my list. I'm lazy, I copied/pasted what you wrote (not
> only this paragraph) :-)
>
> https://cpython-core-tutorial.readthedocs.io/en/latest/what_
> is_a_cpython_core_developer.html
>
> >> * Know the CPython workflow. Be aware of the pre-commit and
> >> post-commits CIs. How ideas are discussed. It's not only about writing
> >> and pushing patches.
> >
> > This part is also required from regular contributors, at least the
> > experienced ones.
>
> Ah yes, I didn't say that these requirements are specific to CPython
> core developers. Most items are "expected" from regular contributors.
> I wrote it explicitly before my list :-)
>
> > Two things I would add:
> >
> > - Know to be nice (...)
> > - Show a bit of humility (...)
>
> Oh, you're right. Thank you for being explicit on these points.
>
> I think that we already expected this from promoted core developers,
> just that it wasn't written down previously.
>
> 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] Should I merge a PR that I approved if it was written by a different core developer?

[Ezio Melotti]

On Wed, Sep 20, 2017 at 11:27 PM, Victor Stinner <victor.stin...@gmail.com>
wrote:

> Hi,
>
> Before the GitHub era, in the old "Mercurial era", the unwritten rule
> was to not merge a patch written by a developer who has the commit
> bit, to not "steal" his/her work. The old workflow (patches attached
> to the bug tracker) didn't allow to easily keep the author. You had to
> find the author email and full name and specify it manually.
>
> Moreover, there was a written rule of using the name of the developer
> who actually pushed the commit, so the commiters took the
> responsability of any regression (reminder the old era with no
> pre-commit CI? ;-)).
>
> In the new Git era, the author and committer *can* be two different
> people. Examples with "git log --pretty=full":
>
> commit 9abee722d448c1c00c7d4e11ce242ec7b13e5c49
> Author: Victor Stinner <victor.stin...@gmail.com>
> Commit: GitHub <nore...@github.com>
>
> commit 8f51bb436f8adfd139cad046b91cd462c7f27f6c (tag: v3.7.0a1)
> Author: Ned Deily <n...@python.org>
> Commit: Ned Deily <n...@python.org>
>
> commit 9b47af65375fab9318e88ccb061394a36c8c6c33
> Author: svelankar <17737361+svelan...@users.noreply.github.com>
> Commit: Raymond Hettinger <rhettin...@users.noreply.github.com>
>
> My question is: is someone opposed that a core developer clicks on the
> [Merge] button for a PR proposed by a different core developer?
>
>
Personally I would prefer if other core devs just left a positive review
without merging, for a few reasons:

1) before merging I want to double check that everything is fine, and
possibly tweak a few minor things before merging.  Some authors also push
WIP or working but unpolished PRs to get some early feedback before
following up with more iterations, and if they don't specify it clearly you
might end up merging too early.
2) even if you are not "stealing their work", you deprive them of the
closure they get by finally merging a PR they have been working on for some
time.
3) some tools (e.g. buildbot) might only look at the committer field, and
this might end up notifying the wrong person or skewing some statistics.
4) I don't see a reason to do that in the first place: I expect the author
to quickly merge a PR once all the checks pass (especially since they can
now do it from their smart watch while lying on the beach), and even if the
author takes a few days to do so, it usually doesn't really matter.


> IMHO having a committer different than the author is valuable since
> the responsability is now shared by two developers instead of single
> one. It's similar to the "Signed-Off" tags used by the Linux kernel,
> but the list is limited to a single Signed-Off :-) Well, the committer
> is usually seen as the most reponsible, but now we can complain to the
> author as well *if needed* :-D
>
>
IME if the author is not a core dev, the responsibility falls on the
committer; if the author is a core dev, the responsibility falls on the
author/comitter (i.e. the core-dev).  If core devs merge their own patches,
the responsible will always be the committer.

If you merge other core devs' patches, you are likely to get blamed when
something breaks even if the code wasn't yours, and if the author runs away
and you want someone else to blame, you can always find all the reviews by
looking at the PR referenced by the changet :)

Best Regards,
Ezio Melotti


> 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] Core sprint 2017 - Sep 4 - Sep 9, Menlo Park, California

[Ezio Melotti]

Hi,
I signed up but haven't heard any news yet.
September is approaching, so it would be great to know if you are still
deciding/negotiating or if you already know the names :)

Best Regards,
Ezio Melotti


On Tue, Jun 13, 2017 at 1:04 AM, Lukasz Langa <luk...@langa.pl> wrote:

> Hello fellow committers!
> I'm organizing another core sprint this year to make Python 3.7 the best
> release possible.
>
> *WHY*:
> 1. *Community*.  The sprints at the end of PyCon are great but they
> mostly get the same people in the room year after year.  Many of the most
> active contributors never attend conferences.  My goal with this sprint is
> to bring together many core devs who rarely if ever meet!
> 2. *Focus*.  When we have sprints at the end of a conference, many of us
> are pretty tired and less productive than we could have been without the
> late dinners, endless hallway sessions, and so on.  Some of the sprinters
> are preoccupied with tutoring newcomers.  This sprint won't be after a
> major conference, and it's only for seasoned CPython core devs--so get to
> work!
> 3. *Communication*. There are tremendous benefits to getting everyone
> together in one big room.  Conversations that drag on on python-dev can be
> solved quickly in person.  Even contentious debates become faster, easier,
> and more civil.  And meeting face-to-face helps us all feel more connected
> to our community.
>
> *WHY THE BAY AREA*: We have a large population of core contributors
> here.  Also, I can arrange for Facebook to provide us a "war room" for the
> whole week, with full access to the campus during the sprints. That
> includes free food for breakfast, lunch, dinner, and snacks, compatible
> with almost any dietary restrictions.
>
> *WHY EARLY SEPTEMBER*: It's almost impossible to find a time that doesn't
> overlap with a PyCon. This week worked well last year so we're redoing it
> that way. Monday September 4 is Labor Day in the US, which may make it
> easier for employees of US companies to attend, as they'd only be taking
> off four days instead of five.
>
> *HOW LONG*: A full week Monday, Sep 4 to Friday, Sep 8 evening. You can
> check into your hotel the day before the sprint (Sunday, Sep 3) and check
> out the day after (Saturday, Sep 9).
>
> *HOW BIG*: No fewer than 10, no more than 20.  More than 20 people would
> be great but it'd be hard for me to organize a sprint that big.
>
> *WHO PAYS*: The venue, hotels, and food are provided by Facebook. I'm
> working on getting flight reimbursements. Last year they were provided by
> the Python Software Foundation. Anybody is free to waive their
> reimbursement.
>
> *PLEASE REPLY*: If you're interested in attending and have the commit bit
> on GitHub's python/cpython, fill out this Google Form:
> https://goo.gl/forms/MzrNtRe0NAmzvGwF2
>
> *DISCLAIMER*: I'd like to be able to host everybody. However, if I
> receive more than 20 applications, this is not going to be possible. In
> this case, the following will happen:
>
> 1. I will look at your current level of involvement in CPython
> development. This includes metrics like commits / PRs, activity on the bug
> tracker and python-dev, special role (release manager, infrastructure dev,
> etc.).
> 2. I will look at your sprint plan and ability to participate in the
> entire sprint (per answers to the questions above).
> 3. I will gather all this data and leave the final decision to our
> Benevolent Dictator (who is also attending the sprint). This is one of
> those occasions where having a dictator is useful.
>
> *DON'T WAIT*: September is closer than you think! Please let me know as
> soon as possible so we can start setting up the event. I'm going to close
> the sign-up form on June 23rd.
>
> Organizational-ly yours,
> Ł
> Vice-Minister of Silly Sprints
>
> ___
> 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] Spurious bugs.p.o messages

[Ezio Melotti]

On Fri, Mar 31, 2017 at 3:59 PM, Terry Reedy <tjre...@udel.edu> wrote:
> On 3/31/2017 6:08 PM, Brett Cannon wrote:
>>
>>
>>
>> On Fri, 31 Mar 2017 at 12:37 Victor Stinner <victor.stin...@gmail.com
>> <mailto:victor.stin...@gmail.com>> wrote:
>>
>> 2017-03-31 20:30 GMT+02:00 Antoine Pitrou <anto...@python.org
>> <mailto:anto...@python.org>>:
>> > Just a heads up that the following PR:
>> > https://github.com/python/cpython/pull/552/files
>> > has generated a lot of spurious PR additions on bugs.python.org
>> <http://bugs.python.org>,
>> > probably because that PR references a lot of issues
>> > (example: https://bugs.python.org/issue23839).
>> >
>> > Perhaps it would be nice to have an upper limit on the number of
>> > notified issues when the PR mentions several of them?
>> >
>> > (I'm sure someone more active than me, such as Victor or Serhiy,
>> got *a
>> > lot* of notifications from that PR :-))
>>
>> Hello, I got 110 emails, something goes wrong? :-)
>
>
> Each link generated an email with a message like
> "pull_requests: +994" but with a different number.
>

The range should be from pull_request826 to pull_request1113.
I tried to unlink a PR from the admin but it still generated an email.
I'm not aware of any method to unlink them without generating emails,
so If you don't mind another wave of emails, I can write a script to
go through them and unlink them from the issues, otherwise I'll just
leave them there. (It might be possible removing them from the db
directly using SQL without generating emails, but I'd rather avoid
touching the db).

>> No, it's a side-effect of having Misc/NEWS pasted as a comment into a PR
>> and the Roundup webhook thinking the issues were comments that warranted
>> connecting the PR with the issue.
>
>
> I consider this wrong ;-).
>
>>  Either we (a) don't worry about it as
>> people typically don't paste Misc/NEWS into a comment, (b) cap the
>> number of possible issues in a single webhook event, or (c) don't pick
>> up issue numbers from comments and only do it from PR titles.
>

I think adding a limit makes sense: 10 issues should probably be
enough, even for meta-issues.
I already started working on a patch, but I'm still thinking what's
the best way to implement it (e.g. limit it to the title only, to
individual messages, to all messages, etc.).

>
> (c), at least until we discover that there is something that needs to
> automated about numbers.
>
> What I would like is that the BPO issue # in the PR title be a link so it is
> easy to jump from PR to BPO.
>

There are some discussion about it, I think on the core-workflow issue tracker.
I'm not up to date, but last time I looked into it the title couldn't
be changed, but it should be possible to use a bot to convert the
issues to links in the message body.  Berker also made a browser
extension[0] that can be used in the meanwhile.

Best Regards,
Ezio Melotti

[0]: https://github.com/berkerpeksag/cpython-bpo-linkify

> --
> Terry Jan Reedy
>
___
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] 4 weeks with the new workflow: what needs changing?

[Ezio Melotti]

On Sat, Mar 11, 2017 at 12:13 AM, Brett Cannon <br...@python.org> wrote:
> I can't believe it's been 4 weeks. It feels like it was ages/yesterday when
> we moved. :)
>
> First, I hope people are not regretting letting/having me make this
> migration. I know there have been some things to work through (and others
> still to come), but I hope this is all a net positive (either now or in the
> near future).
>
> Second, I wanted to get initial feedback on things we can easily tweak:
>
> Requiring Travis to pass (I really don't want to turn this off as we already
> had a broken build when I temporarily turned it off at someone's request
> when Travis was backed up from the AWS S3 outage; I also don't plan to make
> AppVeyor required unless there's a way to make it be skipped for doc-only
> changes)
> Cherry-picking working out? (We can go back to forward merging if people
> really want to, but I think long-term cherry-picking will allow for more
> automation)
>
> Along with that, are the labels for cherry-picking working out? (Some devs
> seem to like using title labels like `[3.6]` to flag cherry-picks so it's
> more obvious in emails so I don't know if the labels are really that useful)
>
> Is the mention bot helpful? (Our config is at
> https://github.com/python/cpython/blob/master/.mention-bot and the docs are
> at https://github.com/facebook/mention-bot)
> Anything to tweak about the coverage bot and reports? (Our config is at
> https://github.com/python/cpython/blob/master/.codecov.yml and docs at
> https://docs.codecov.io/docs/codecov-yaml)
>
> Third, I wanted to point out some of the more critical discussions going on
> at https://github.com/python/core-workflow/issues. Specifically,
> https://github.com/python/core-workflow/issues/6 is working towards a
> solution for Misc/NEWS so if you care about the final solution you should
> participate there. After Misc/NEWS is solved the next step becomes solving
> the cherry-picking overhead with a more automated approach. We are also
> discussing closed branches to make the list of branches more manageable at
> https://github.com/python/core-workflow/issues/31.
>
> Fourth, the lack of messages showing up on bugs.python.org after a commit is
> being tracked at http://psf.upfronthosting.co.za/roundup/meta/issue613. I'm
> sure Ezio and Maciej would appreciate any help people may be able to
> volunteer to help in solving the problem.
>

I'm planning to look at this next week (if Maciej doesn't beat me to it).
FTR we have been working on a docker container that contains a test
instance of the tracker: https://github.com/python/docker-bpo/
Even though there are still a few rough edges, it's now pretty
straightforward to get a test tracker up and running.
Next we are planning to make a script to test/debug GitHub payloads
(so I can easily debug issue613) and eventually we will put the image
on DockerHub.

> Fifth, anything I missed? :)
>

I find the documentation in the devguide still lacking.
I've been trying to improve it, but first I have to figure out all the
details of the new workflow.

Best Regards,
Ezio Melotti
___
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] Mercurial commit url is broken

[Ezio Melotti]

On Thu, Feb 16, 2017 at 3:30 PM, Victor Stinner
<victor.stin...@gmail.com> wrote:
> Hi,
>
> I clicked on a Mercurial commit number from:
> http://bugs.python.org/issue18383#msg249581
>
> It points me to:
> http://hg.python.org/lookup/c1396d28c440
>

FTR the URL works now -- not sure if someone fixed it in the meanwhile.

Best Regards,
Ezio Melotti

> ... which displays short error message:
> ---
> Usage: /lookup/GITHEXHASH or gitGITHEXHASH (10, 11, or 40 hex characters)
> /lookup/HGHEXNODE or hgHGHEXNODE (12 or 40 hex characters)
> /lookup/rSVNREVISION
> ---
>
> "c1396d28c440" hash is 12 hex characters long.
>
> 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/

Re: [python-committers] New Roundup notifications on Git commits?

[Ezio Melotti]

On Thu, Feb 16, 2017 at 2:10 AM, Victor Stinner
<victor.stin...@gmail.com> wrote:
>> New changeset 72e81d00eee685cfe33aaddf2aa9feef2d07591f by Victor Stinner in 
>> branch 'master':
>
> Ok, I confirm that I now get notifications. Cool :-)
>
> New request (!): would it be possible to mention the author instead of
> the commiter? Or maybe mention both?
>

If GitHub passes the information along (and it probably does), then it
should be possible to have both.
Please create an issue on the meta-tracker to keep track of this.

Best Regards,
Ezio Melotti

> Thanks,
> 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/

Re: [python-committers] New Roundup notifications on Git commits?

[Ezio Melotti]

On Mon, Feb 13, 2017 at 8:16 PM, Brett Cannon <br...@python.org> wrote:
> There was an issue up until sometime on Sunday where the SSL cert for
> bugs.python.org was being rejected (it was issued by StartCom who is being
> distrusted). The cert got replaced but if the webhook event for your merge
> got rejected due to the bad cert then it would have been dropped.
>

Today I also spotted and fixed another issue, and verified that now
the messages are showing up on bpo (see e.g.
http://bugs.python.org/issue29557#msg287801).  Let me know if there
are other issues.

Best Regards,
Ezio Melotti

> So if should be working, but you may have been caught in the SSL problem. If
> it persists then there's a problem in the hook-side of bugs.python.org that
> will need fixing.
___
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] Discussions on PRs

[Ezio Melotti]

On Mon, Feb 13, 2017 at 11:33 AM, M.-A. Lemburg <m...@egenix.com> wrote:
> With the move to Github, I'm seeing a move away from
> discussions on the issue tracker towards discussions on
> pull requests.
>
> Example: https://github.com/python/cpython/pull/4
>
> Is this something we should encourage or better ask the OPs
> to open a ticket on the tracker first and reference the PR
> there ?
>

Unless it's a trivial PR (e.g. typo fix), then there should be a
discussion on bpo.  The devguide has been/is being update to be more
clear about this aspect.

> Discussion on the PRs would then only be for code review
> aspects.
>

Yes, discussions on the PRs replace the discussions we had on Rietveld
-- they should only be about the code review.

Best Regards,
Ezio Melotti

> Thanks,
> --
> Marc-Andre Lemburg
> eGenix.com
___
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] New Roundup notifications on Git commits?

[Ezio Melotti]

I've been keeping an eye on the tracker logs and saw no errors.  If
you are still having problems after the SSL fix let me know.

On Mon, Feb 13, 2017 at 8:16 PM, Brett Cannon  wrote:
> There was an issue up until sometime on Sunday where the SSL cert for
> bugs.python.org was being rejected (it was issued by StartCom who is being
> distrusted). The cert got replaced but if the webhook event for your merge
> got rejected due to the bad cert then it would have been dropped.
>
> So if should be working, but you may have been caught in the SSL problem. If
> it persists then there's a problem in the hook-side of bugs.python.org that
> will need fixing.
>
> On Sun, 12 Feb 2017 at 13:59 Victor Stinner 
> wrote:
>>
>> Hi,
>>
>> I merged my pull request:
>> https://github.com/python/cpython/pull/12
>>
>> which has a commit message starting with "bpo-29524: ", but the issue
>> wasn't updated (no new comment to mention the comit):
>> http://bugs.python.org/issue29524
>>
>> The final commit is:
>>
>> https://github.com/python/cpython/commit/c22bfaae83ab5436d008ac0d13e7b47cbe776f08
>>
>> Is it a known issue? Should I mention the issue number differently?
>>
>> 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/
___
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] My cavalier and aggressive manner, API change and bugs introduced for basically zero benefit

[Ezio Melotti]

On Sat, Jan 21, 2017 at 9:51 PM, Brett Cannon <br...@python.org> wrote:
> What I'm picking up from this is (as a gross oversimplification):
>
> * Victor _wants_ code reviews
> * Raymond thinks we _need_ code reviews
>
> So the common theme here regardless of whether you agree with Raymond or
> Victor's approach to development is that we are not getting enough code
> reviews to go around. To me that's what the systemic issue is that this
> email is bringing up.
>
> Now I think most of us don't think the solution to the lack of reviews is to
> lower our standard of what it takes to become a core developer (this doesn't
> mean we shouldn't do a better job of identifying potential candidates, just
> that we shouldn't give people commit privileges after a single patch like
> some projects do). To me that means we need to address why out of 79 core
> developers only 39 have a single commit over the past year, 30/79 have more
> than 12 commits over that same time scale, 15/79 people have more than 52
> commits, and 2/79 people have over 365 commits
> (https://github.com/python/cpython/graphs/contributors?from=2016-01-22=2017-01-21=c
> for the stats).
>
> Some of you have said you're waiting for the GitHub migration before you
> start contributing again, which I can understand (I'm going to be sending an
> email with an update on that after this email to python-dev &
> core-workflow). But for those that have not told me that I don't know what
> it will take to get you involved again.

I can tell you what drove me away:
1) real life got in the way, time is limited;
2) I spend the available time working on the bug tracker rather than
on core Python, since my time is likely more valuable if spent on bpo;
3) MLs are quite high traffic, and I gave up keeping up /for now/ [0]
(I have 6.8k unread mails from python-checkins, 460 from
python-issues, 320 from python-dev).  This also means that:
  a) if a bug related to one of the modules I maintained is opened, I
won't see it[1];
  b) if a message explicitly asks for my opinion/review, I won't see it[1];
4) the GitHub migration (first I was against, now I'm waiting for
everything to settle and then give it a try, in future I hope it will
become a reason to get me involved again);
5) the more time I spend away, the more difficult it becomes to follow
all the new features that get introduced.

As for what would get me involved again, for my case there's not much
else you can do -- I just need to find more free time, catch up with
development (mails, tools, features, etc) and then try to keep up.

Best Regards,
Ezio Melotti

[0]: FWIW one thing that helped me keeping the mail traffic low(er),
was following the weekly issues reports on python-dev, and adding
myself to nosy on the issues I cared about, rather than subscribing
and following the other mailing list (python-bugs-list and
new-bugs-announce).
I also used to keep an eye on #python-dev for new issues and replies,
and I wish more core-devs would hang around there, since it makes
communication (including asking for opinions/reviews) much faster.

[1]: Feel free to reach to me directly, either on IRC or via direct mail.

> For instance, not to pick on Andrew
> but he hasn't committed anything but he obviously still cares about the
> project. So what would it take to get Andrew to help review patches again so
> that the next time something involving random comes through he feels like
> taking a quick look?
>
> As I have said before, the reason I took on the GitHub migration is for us
> core developers. I want our workflow to be as easy as possible so that we
> can be as productive as possible. But the unspoken goal I have long-term is
> to get to the point that even dormant core devs want to contribute again,
> and to the point that everyone reviews a patch/month and more people
> reviewing a patch/week (although I'll take a patch/year to start). I want to
> get to the point that every person with commit privileges takes 30 minutes a
> month to help with reviews and that the majority of folks take 30 minutes a
> week to review (and please don't think this as a hard rule and if you don't
> the privileges go away, view this as an aspirational goal). Even if people
> who don't have time to review the kind of patches Victor is producing which
> triggered this thread, reviewing documentation patches can be done without
> deep knowledge of things and without taking much time. That way people who
> have time to review the bigger, more difficult patches can actually spend
> their time on those reviews and not worrying about patches fixing a spelling
> mistake or adding a new test to raise test coverage.
>
> All of this is so that I hope one day we get to the point where all patches
> require a review no matter who proposed the code change. Now I think we're
> quite 

Re: [python-committers] commit privs given to Maciej Szulik for bugs.python.org work

[Ezio Melotti]

On Sat, Dec 24, 2016 at 12:37 AM, Victor Stinner
 wrote:
> 2016-12-23 19:07 GMT+01:00 Brett Cannon :
>> Maciej has been helping Ezio, David, and me out with updates to
>> bugs.python.org for the GitHub migration and he's reached a point where we
>> are all comfortable with him making updates to the issue tracker's code
>> without us holding him up. He knows not to commit to Python itself or other
>> repos.
>
> Push to which repository?
>

https://hg.python.org/tracker/

> Aren't we moving to GitHub where a project can have multiple teams, so
> different groups of people, instead of a single monolithic team?
>

Eventually yes, even though h.p.o/tracker won't probably be ported to
GitHub (see core-workflow thread "GitHub migration update for
2016-12-19").
With his help we should be able to complete the migration faster, and
then make all the teams we need.

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

Re: [python-committers] Making the PSF CoC apply to core developers

[Ezio Melotti]

On Sat, Feb 27, 2016 at 7:17 PM, Brett Cannon <br...@python.org> wrote:
>
>
> Python-ideas has been under the same CoC for a while now and it has been
> nothing but positive. When people know they are expected to behave in a
> civil manner and others know they are allowed to call someone out for being
> uncivil it typically is enough to make people behave.
>
> So there is no issue of people "being overburdened by regulations". The CoC
> only comes up when someone is being so rude that they need to be talked to
> about their attitude  problem, so as long as we try and keep people from
> being rude  it won't come up. Quite frankly, the CoC is really just meant as
> a way for people to feel comfortable in knowing they don't have to tolerate
> jerks. And I would hope none of us are jerks to people in the community, so
> saying as much shouldn't change anything for any of us. This also lets the
> community know that we don't view ourselves as some elite group of people
> whose attitudes must be tolerated no matter what; we hold ourselves to the
> same standards as the rest of the community does and it should be pointed
> out as such to make people feel comfortable.
>

It seems to me that the "controversies" raised in this thread stem
from a few underlying problems and points of confusions.

The first problem is that it is not entirely clear (at least to me)
why we need a CoC and what problem is the CoC trying to solve.  The
CoC itself simply mentions: "[...] these guidelines [...] help steer
our interactions and strive to keep Python a positive, successful, and
growing community.".  Clearly stating the goal of the CoC will help
people understand why it is useful.

The second problem is that Code of Conducts usually outline rules[0],
and this can be perceived as limiting one's freedom and potentially be
abused for censoring users.  Our CoC however is quite "mild", so I
believe people that expressed concern were mostly against the idea of
having a CoC, rather than being against our CoC in particular.
However is also not clear what measures -- if any -- will be taken to
enforce the CoC[1].

Which bring us to the the third problem: if, how, and by whom these
"guidelines" are enforced.  Enforcement requires judgment, and
judgment requires judges.  Who is to judge if e.g. one or more mails
in broken English, or with a perceived rude tone, or with unrealistic
proposals are detrimental to the conversation and should be "rejected"
or if they should be accepted/tolerated/embraced in the spirit of
inclusiveness?  If they are "rejected", what specific actions are
going to be taken?


ISTM that our CoC simply puts black on white the general principles
that we have already being following, without outlining any hard
rules. It should therefore have little to no effects -- both positive
and negative -- on existing members.  It might however serve as a
remainder to people that disregard (intentionally or not) these
principles, and help shaping the image of our community for external
people -- including potential new members of our community.

Best Regards,
Ezio Melotti


[0]: "A code of conduct is a set of rules outlining the social norms
and rules and responsibilities of, or proper practices for, an
individual, party or organization." --
https://en.wikipedia.org/wiki/Code_of_conduct

[1]: "Studies of codes of conduct in the private sector show that
their effective implementation must be part of a learning process that
requires training, consistent enforcement, and continuous
measurement/improvement." --
https://en.wikipedia.org/wiki/Code_of_conduct
___
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] Deprecation Policy PEP

[Ezio Melotti]

On Sat, Jan 30, 2016 at 4:08 AM, Martin Panter  wrote:
>> What and when to deprecate
>> ==
>>
>> * The number of releases before an API is removed is decided
>>   on a case-by-case basis depending on widely used the API is
>
> depending on [how] widely used
>
>> * In general it's better to be conservative, and if the API is
>>   deprecated in ``3.X``, it shouldn't be removed before ``3.X+2``.
>>   This should also take into account which Python versions are
>>   currently .
>
> which Python versions are [current].
>
> More explicitly, I would say as a guideline, if the proposed
> alternative is unavailable in 3.Y, consider waiting until 3.Y becomes
> unsupported or unused before removing (or even fully deprecating) an
> API.
>
>> Porting from 2.x to 3.x
>> ---
>>
>> In order to make porting code to 3.X easier:
>>
>> * nothing that is available and not deprecated in 2.7 should be
>>   removed from Python 3 as long as 2.7 is officially supported;
>
> What about an API not documented in Python 3, like
> http.client.HTTPMessage.getallmatchingheaders()
> ? In this case I think the method
> was rendered useless in 3.0 and it is not worth fixing.
>

The goal is to avoid unnecessary breakage.  In this case the code will
need to be fixed regardless, so the best we can do is to add a -3
warning to 2.7 .

> Also I presume you mean not originally deprecated in 2.7.0. In other
> words adding a “python2 -3” warning in the next 2.7 bug fix doesn’t
> give me a license to remove an API from 3.6.
>

Yes, even if you could argue that even removing things that were
already deprecated will make porting more difficult.  Perhaps I should
rephrase the section focusing the working on making the porting
easier.

>> Deprecation Progression
>> ===
>>
>> 1. in release ``3.X`` a ``DeprecationWarning`` is added
>> 2. in release ``3.X+N`` the API is removed
>>
>> ``N`` can be ``>=1``, should be decided beforehand, and should be
>> documented explicitly.
>
> How do we decide on the value of N for something that has to wait
> until 2.7 is dead? Just estimate based on anticipated future release
> dates? E.g. inspect.getargspec(). In some cases I think indefinite
> deprecation is better.
>

An estimation is fine.
I would use 4.0 for indefinite deprecations.  If we use the rst
directives to collect all the deprecated APIs in a single page, we can
go through them once 2.7 is dead.

>> Deprecation Process
>> ===
>
>> 2. attach to the issue a patch to deprecate the API that:
>>
>>   * adds a ``DeprecationWarning`` to the code
>>   * adds the deprecation to the documentation
>>   * adds a test to verify that the warning is raised
>
> Often people propose a test that will detect when the version changes
> to >= X+N and complains if the API has not been removed. Should this
> be encouraged or discouraged?
>

I did it once and it ended up breaking tests in the middle of the next release.
For the sake of the release managers, I don't think it should be done,
especially if we come up with a better way to track deprecations.

>>   * possibly updates code/examples that uses the deprecated API
>
> Also adjust any tests to suppress the new warning. Code to do this
> typically looks like
>
> with warnings.catch_warnings():
> warnings.simplefilter("ignore", DeprecationWarning)
> deprecated.api()
>

For tests there should be a convenience function in test.support.

>> 3. after review, apply the patch to the current in-development
>>branch and close the issue.
>
> Also apply similar changes to 2.7 if applicable?
>
>> Documenting the deprecations
>> 
>>
>> * All deprecations should be documented in the docs, using the
>>   ``deprecated-removed`` directive.
>
> If an undocumented API is being deprecated, you may not have to touch
> the main documentation (but still consider a notice in What’s New).
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

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

[Ezio Melotti]

On Tue, Jan 5, 2016 at 7:38 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 5 January 2016 at 11:33, R. David Murray <rdmur...@bitdance.com> wrote:
>> On Tue, 05 Jan 2016 01:26:58 +, "Gregory P. Smith" <g...@krypto.org> 
>> wrote:
>>> On Mon, Jan 4, 2016 at 12:34 PM R. David Murray <rdmur...@bitdance.com>
>>> 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.
>>
>> Yes, collision is not the problem, it's that you can't distinguish them
>> without a lookup table or something.  Which means we have to do more
>> than just change the URL in the existing linkifier, which was my point.
>
> In the specific case of Roundup, does the linkifier have the "date of
> comment" info available? If so, it could fairly readily assume that
> hashes prior to the cutover date are hg ones, and later ones are for
> git.

By looking at the code I don't see it readily available, but it might
be possible to retrieve it somehow.
However I think it's better to keep the linkifier simple and stupid
and just delegate to https://hg.python.org/lookup/ .

Best Regards,
Ezio Melotti

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

Re: [python-committers] emails from bugs.python.org are marker as spam

[Ezio Melotti]

On Thu, Nov 19, 2015 at 12:40 AM, Yury Selivanov
<yselivanov...@gmail.com> wrote:
> Most of the emails from bugs.python.org (and review tool) end up being
> marked as spam in gmail.  I consistently miss 70% of them. Is it possible to
> fix this?
>

A quick workaround is to create a GMail filter and check "never send to spam".

The issue is also being discussed at
http://psf.upfronthosting.co.za/roundup/meta/issue562

Best Regards,
Ezio Melotti

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

[Ezio Melotti]

Hi,

On Fri, Jan 9, 2015 at 11:47 PM, M.-A. Lemburg m...@egenix.com wrote:
 On 09.01.2015 23:26, Ezio Melotti wrote:
 Hi,

 On Fri, Jan 9, 2015 at 1:09 PM, M.-A. Lemburg m...@egenix.com wrote:

 BTW: How about having an incubator phase for new core devs ?
 The new candidate will get commit rights for say 3 months and
 after those 3 months, the mentor then suggests whether make
 the status permanent or not.


 Not sure this will work too well.  I'm assuming that new candidates
 are good developers and reasonable persons that will still be chosen
 based on their merits (previous contributions, recommendations from
 other core devs, etc.), so nearly all of them will probably get the
 permanent status.
 I can't imagine many reasons why we wouldn't eventually accept a
 candidate.  If they wreak havoc in the repo we will probably remove
 their commit rights immediately, if they do something wrong we would
 just tell them and they would hopefully fix the problem and keep it in
 mind for the next time.  If they really can't figure out/follow our
 workflow or have similar problems they will probably gave up being
 contributors on their own, even if they still have rights.

 As long as this is stated clearly from the beginning, I don't
 think people will feel offended if they end up not receiving
 the permanent status, and this will reduce the barrier for
 entry a lot. Learning on the job is a rather common practice
 in the industry these days :-)


 If they do something clearly wrong they shouldn't be surprised if we
 revoke their right, 3 months period or not.  If they are just not good
 enough they won't be offended but they will probably be disappointed.
 Comparing Python with a paid job is also somewhat misleading, since
 the only investment we have to do is following the new contributor for
 a while and possibly intervene if something goes wrong (e.g. they made
 a wrong commit and don't know how to fix it/revert it).  IME this
 doesn't happen often and it's not a particularly time-consuming task.

 TL;DR We can give access rights to whoever proves to be up to the task
 and willing to contribute, the three month period is not necessary, if
 they cause trouble we will just revoke the right (but that shouldn't
 happen).

 Perhaps I wasn't clear about the context. The discussion was
 focusing on requirements for a new developer to get commit
 rights.

 Antoine and Victor argued that new developers should first
 show their skills by submitting patches to tickets, working
 with other core devs before getting the commit bit set.


IMHO if the contributors are already known for their skills, then they
just need to submit a couple of patches.  This is useful both for the
contributors (so they get the hang of it and learn the workflow) and
for the team (so we see they understand the workflow and they are
indeed up to the task).  If everything is fine then they can get the
commit bit.  This group includes devs that already work on other
projects/Python implementations, that have successful packages on
PyPI, or that are recommended by other core devs.

If the contributor is relatively unknown, then he/she has to prove
that he/she is up to the task by contributing a larger number of
patches before getting the commit bit.

 My suggestion was allowing new developers to start committing
 patches themselves before having worked on dozens of tickets
 using the usual patch approach.


The usual patch approach varies from person to person.  Some
contributors works on dozen of trivial issues before moving to
something more complex, others specialize on a single package, others
are able to tackle difficult issues right away.  Working on a few
difficult issues often tells more about the skills of the contributor
than working on dozen of trivial ones.
Since most contributors start with simpler issues, it is not uncommon
that by the time they are comfortable working on complex issues and
become core devs they already contributed several patches.

 The incubator phase is meant to check whether the new developer
 is up to the task he or she signs up for. The mentor keeps checking
 the code quality during this phase to avoid broken code or
 backwards incompatible changes which would need more discussion.


This should happen before the code is committed, so it doesn't matter
if they have commit rights or not.

 In summary, we'd allow developers to start taking on responsibilities
 earlier than in the current process, while still maintaining
 the high quality standards we have.

 I may be misunderstanding your reply, but it appears you'd even
 want to go beyond that, so we're not really in disagreement it
 seems :-)


IMHO people can get the commit bit once they proved they are up to the
task and contributed at least a couple of patches (for the reasons
stated above).

Best Regards,
Ezio Melotti
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman

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

[Ezio Melotti]

Hi,

On Fri, Jan 9, 2015 at 1:09 PM, M.-A. Lemburg m...@egenix.com wrote:

 BTW: How about having an incubator phase for new core devs ?
 The new candidate will get commit rights for say 3 months and
 after those 3 months, the mentor then suggests whether make
 the status permanent or not.


Not sure this will work too well.  I'm assuming that new candidates
are good developers and reasonable persons that will still be chosen
based on their merits (previous contributions, recommendations from
other core devs, etc.), so nearly all of them will probably get the
permanent status.
I can't imagine many reasons why we wouldn't eventually accept a
candidate.  If they wreak havoc in the repo we will probably remove
their commit rights immediately, if they do something wrong we would
just tell them and they would hopefully fix the problem and keep it in
mind for the next time.  If they really can't figure out/follow our
workflow or have similar problems they will probably gave up being
contributors on their own, even if they still have rights.

 As long as this is stated clearly from the beginning, I don't
 think people will feel offended if they end up not receiving
 the permanent status, and this will reduce the barrier for
 entry a lot. Learning on the job is a rather common practice
 in the industry these days :-)


If they do something clearly wrong they shouldn't be surprised if we
revoke their right, 3 months period or not.  If they are just not good
enough they won't be offended but they will probably be disappointed.
Comparing Python with a paid job is also somewhat misleading, since
the only investment we have to do is following the new contributor for
a while and possibly intervene if something goes wrong (e.g. they made
a wrong commit and don't know how to fix it/revert it).  IME this
doesn't happen often and it's not a particularly time-consuming task.

TL;DR We can give access rights to whoever proves to be up to the task
and willing to contribute, the three month period is not necessary, if
they cause trouble we will just revoke the right (but that shouldn't
happen).

Best Regards,
Ezio Melotti
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Mark Lawrence

[Ezio Melotti]

On Oct 6, 2014 9:16 AM, Terry Reedy tjre...@udel.edu wrote:

 On 10/6/2014 1:02 AM, Nick Coghlan wrote:

 On 6 October 2014 07:22, Terry Reedy tjre...@udel.edu wrote:

 On 10/5/2014 3:39 PM, Terry Reedy wrote:


 I responded on the issue,
 and will say more privately.


 I wrote him and tried to communicate three ideas.
 1. Closing issues and responding to new messages, while important, are
 subsidiary to the primary goal of improving Python.
 2. We would prefer more quality and less quantity.
 3. We each set our priorites; he should not try to do so for us.


 Thanks Terry.

 I know Mark is particularly concerned about the open issues tally
 and constantly seeks ways to bring that down.


 I think I can suggest some better ways.


A while ago I talked with him about this issue, and suggested him to write
down all the interesting issues on a list and mail it to python-dev once
a week, instead of pinging the issues individually.

He followed my suggestion and sent the list, but iirc no one replied, so he
probably deemed the approach ineffective and went back to pinging the
issues.

I also suggested him to work on the bug tracker code or on similar projects
-- not sure if he gave that a try yet.

Best Regards,
Ezio Melotti


 Scattergun pinging of
 open issues is one of the easiest, but also one of the ones with a
 high hidden cost in annoying people - for developers, it may mean
 getting dozens of email notifications, for issue submitters, it may
 lead to anticipation of action, only to be disappointed when it's just
 a ping asking for a status update.


 Since all aspects of this annoyance were not completely obvious to me, I
am sure they are not to him.  With the discussion here, I understand much
better and will try to explain to him.

 Terry

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

Re: [python-committers] Anatoly has been warned about his behaviour potentially leading to his loss of tracker privileges

[Ezio Melotti]

Hi,
as I already mentioned in a message on a previous thread, I'm -1 on banning him.
Last time this issue came up I contacted him and we discussed about
these problems several times.  For a while things got better and hhis
behavior got a bit better and his posts less frequent, but lately he
got active again.

If you try to get in his shoes, you can see how his behavior kind of
makes sense -- even thought results are far from ideal:
  1) he wants to improve Python and fix problems that affect or might
affect him -- this is completely understandable and reasonable;
  2) however, he read the CLA and disagrees with/doesn't understand a
few things -- this also is somewhat reasonable and shared by a few
other persons; the fact   that most of the others don't care / trust
it and just sign it without even reading doesn't mean that he's wrong;
  3) without a signed CLA he is unable to contribute code (even if
he's otherwise willing and able to do so), and this places him in a
very frustrating position where he his not able to fix things himself
and has to rely on others;
  4) in an attempt to catch the attention of others he relies on
passive-aggressiveness -- likely because he thinks this is the most
effective tool he has available;

His behavior does catch our attention (giving the impression of
(short-term) effectiveness), but in a negative way.  There's also a
vicious circle where our behavior towards him increases his
frustration and leads him to complain louder in an attempt to
compensate; the fact that we already start with a negative bias
against him doesn't help either.

I also agree with Ned when he says:

On Sat, Nov 30, 2013 at 12:41 AM, Ned Deily n...@acm.org wrote:

 [...]  I personally don't see his behavior, in and of itself, as all that 
 harmful.  I *do* see the negative reaction it provokes as being harmful. [...]


That said, I think a ban will make him even more frustrated, and that
might lead to two outcomes:
  1) he will eventually gave up (and make some people happy);
  2) he will likely still face problems with Python that he wants to
fix and he will have to find other ways to report them, since the
regular ways have been precluded to him, thus perpetuating the
aforementioned vicious circle.

I personally don't have problems talking with him, and, if we decided
not to ban him, I'm available to spend more time talking with him and
being a mediator.  I'm not very active on the mailing lists, but I
don't mind taking actions on the bug tracker (so feel free to add me
to the issues he reports -- especially if he causes problems).

I also agree that if people don't want to discuss with him on the MLs
they should just ignore his messages, and especially they should avoid
replying with attacks against him or his behavior, rather than
attacks against his proposals.  I've already seen a few of his
threads that got ignored for a few weeks before he pinged the thread
only to be ignored again, so this method seems somewhat effective.
(And FTR I don't think I'm wasting my time -- if anything I'm
sharpening my already nearly-limitless patience ;).

Best Regards,
Ezio Melotti
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] The evolution of HTMLParser

[Ezio Melotti]

On Wed, Nov 20, 2013 at 10:34 PM, Antoine Pitrou anto...@python.org wrote:
 On mer., 2013-11-20 at 21:57 +0200, Ezio Melotti wrote:
 Now I'm working on #13633 (Automatically convert character references
 in HTMLParser [1]), and I'm planning to add a convert_charrefs boolean
 flag to the constructors that, when set to True, will automatically
 convert charrefs (e.g. quot;, #34;) to the corresponding Unicode
 characters, and avoid calling the handle_charref/handle_entityref
 methods.

 How about a separate StandardHTMLParser class that would have the right
 handle_charref / handle_entityref implementations?
 (you could also change other behaviours in that class if desired)


When convert_charrefs is True, handle_charref/handle_entityref are not
called at all.
This is in part because there's no easy way to tell where an invalid
charrefs ends (e.g. if the ';' is missing), so the parser would either
have to only find correctly terminated charrefs (but that doesn't
allow to handle invalid HTML5 entities) or it will have to apply the
HTML5 algorithm (or a subset of it) to find what might be a charref,
and then the user will have to do it again to find the corresponding
character.

So, for example, passing pfoogt;bar/p to the parser currently results in:
  1) a call to handle_starttag with p;
  2) a call to handle_data with foo;
  3) a call to handle_entitydef with gt;;
  4) a call to handle_data with bar;
  5) a call to handle_endtag with p;
The user has then to write the code in handle_entitydef to convert
gt; to  and then do foo +  + bar before getting the
content of the paragraph, i.e. foobar.

With the proposed patch, the parser gets all the text between tags,
and then passes it to html.unescape() to convert all the charrefs
according to the HTML5 algorithm, so the example above becomes:
  1) a call to handle_starttag with p;
  2) a call to handle_data with foobar;
  3) a call to handle_endtag with p;

This also happens in the core of HTMLParser, so in order to create a
subclass where charrefs are converted automatically and without the
handle_charref/handle_entityref, I would also have to duplicate (or
reorganize) lot of code.

Also while parsing arbitrary HTML you might or might not get charrefs,
so the only use cases left are I can think of are:
  * preserving the entities -- this can be done by setting
convert_charrefs=False and returning what gets passed to
handle_charref/handle_entityref or by using html.escape() after the
parsing (the output might be different though);
  * using a different set of charrefs -- xml and html4 are subsets of
the html5 charrefs so they are covered, for other sets it's still
possible to keep using convert_charrefs=False (and people will have
time till 3.5/3.6 to add it before the default changes);
(Note that unlike the strict argument/mode, I don't plan to remove
convert_charrefs -- only to make it default to True.)

Best Regards,
Ezio Melotti

 Regards

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

Re: [python-committers] Zachary Ware for commit access?

[Ezio Melotti]

On Fri, Nov 1, 2013 at 5:50 AM, Brian Curtin br...@python.org wrote:

 Hi all,

 [...]

 Any thoughts?


+1
I committed many of his patches this year and I think it's about time he
gets commit access.  The fact that he is also interested in Windows makes
him an even more valuable addition to the team.
I can also help supervising him if necessary.

Best Regards,
Ezio Melotti
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] [Infrastructure] [Pydotorg] XSS security issue

[Ezio Melotti]

Hi,

On Mon, Jul 15, 2013 at 2:08 PM, R. David Murray rdmur...@bitdance.com wrote:
 On Mon, 15 Jul 2013 11:09:08 +0300, Michael Foord mich...@voidspace.org.uk 
 wrote:

 On 15 Jul 2013, at 11:05, M.-A. Lemburg m...@python.org wrote:

  Who would be the one to contact for issues like these ?
 
  The case is rather urgent, since the XSS can be used for stealing
  session cookies on *.python.org.
 
  The sorting by password issue is a more obscure one. Just removing
  the feature to sort by password should be enough to solve it.

 Technically it's an infrastructure issue (cc'd), but fixing the code of 
 roundup is hardly their domain.

 Ezio Melotti (cc'd) did a lot of work on the Python installation of roundup, 
 so he may have a better idea.

 We have a security mailing list but that is mainly intended for security 
 issues in the language:

   secur...@python.org secur...@python.org

 The OP also emailed security (which I heard about via IRC, I'm not
 on that list).

 Ezio is a Roundup developer, so he is indeed the best person to look
 at the XSS issue, since it is a Roundup problem and not specific to
 the Tracker.  I can take a look too but he is more knowledgeable
 than I about roundup itself.


I don't have time to look at this now, and it might take up to 2 weeks
before I find some time.
The fix is usually as simple as adding a call to escape() in the right
spot, but finding the right spot and testing that the fix works might
take some time.
Before doing this, our Roundup instance should be updated (1.5.0 has
been released recently, but AFAIK it doesn't included a fix for this).
FTR the issue has been reported upstream at
http://issues.roundup-tracker.org/issue2550817.

Best Regards,
Ezio Melotti

 There is another problem which is specific to our tracker and which is the
 bigger issue right at the moment.  We have a 'nobody' user with a blank
 password and Developer privileges.

 I'm about to go out, so I don't want to make a change that might break
 something right this moment, but anyone with the Coordinator role
 could take this on if they want to do it right now:  remove either the
 Developer role, or both roles, from that user and see what happens.
 I suspect that user should not exist at all, but I don't know for sure.

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

Re: [python-committers] Language Summit at EuroPython

[Ezio Melotti]

Hi,

On Wed, Jun 26, 2013 at 4:02 AM, Larry Hastings la...@hastings.org wrote:

 We didn't have one last year because nobody had anything to say.

OK, I asked because the language summit usually happens the day before
the beginning of the conference, and I had/have to plan the travel.

  If you're
 (gentle reader) going to be at EuroPython and think you have something that
 needs discussng, please feel free to email me.

I don't have any outstanding issues I need to discuss about, even
though I would still like to get the regex module included in 3.4.
This can probably be discussed informally during the conference if
someone is interested.

Best Regards,
Ezio Melotti

  If I get a lot of topics
 I'll inquire about getting a room set aside for a couple of hours.

 Cheers,


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

[python-committers] Language Summit at EuroPython

[Ezio Melotti]

Hi,
are there any plans about doing a language summit at EuroPython this year?

Best Regards,
Ezio Melotti
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] hg clone cpython newrepo aborts

[Ezio Melotti]

On Tue, May 28, 2013 at 9:47 PM, Terry Reedy tjre...@udel.edu wrote:
 On 5/28/2013 10:19 AM, Dirkjan Ochtman wrote:

 It's possible something broke with the @-filename.

 I am planning to change '@' to '_' anyway.


What's wrong with just README or README.txt?

Best Regards,
Ezio Melotti
___
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?

[Ezio Melotti]

On Fri, May 24, 2013 at 7:39 PM, Antoine Pitrou solip...@pitrou.net wrote:

 Brett wrote:
 Of course, we've talked about doing something like this before, it's
 just never irritated anyone enough for them to sit down and *write*
 the associated NEWS file generator, or the code to split the existing
 NEWS file for the active branches :)

 I think that's overly complicated.

 Agreed. I'm not surprised Twisted uses something like that :-), but we
 don't need
 that level of complexity.


Agreed.

For me, in the best case scenario hg takes care of the merge; in the
worst, kdiff3 pops up and I have to press CTRL and 3, 2, s, q (to
include the two conflicting news, save and quit respectively).
Solving the merge conflict is not something that really bothers me,
and even when hg merge screws up, doing a revert and copying the news
entry manually is not really cumbersome (and it doesn't happen really
often anyway).

I understand that some people don't use and/or they are not sure how
to use merge tools, but spending 10 minutes to install kdiff3 (or
similar tools) and learn how to use it is a good investment IMHO*.

 I don't see why we need anything
 more than simply NEWS/3.4, NEWS/3.3, etc. and just split the files per
 feature release since that's the interest (and merge) boundary.

 You'll have to copy stuff by hand, though, if you don't want to rely on the
 merge machinery. So we have two possible file layouts:

 * (current) a single Misc/NEWS is merged from branch to branch. Pro: hg merge
 copies the text for you. Con: hg merge sometimes screws up and you have to
 clean up a large conflict.

 * a dedicated Misc/NEWS-x.y per major version. Pro: no merge conflicts ever.
 Con: you have to copy the message by hand when merging a bug fix to the upper
 branch. Con: it's easy to forget to copy the message (hg won't yell if you
 don't
 do it), so people *will* forget (and it's annoying grunt work for those who
 notice it).

 The major con with the current scheme *might* be solved by a dedicated hg
 extension, but someone needs to have enough free time and passion to try and
 write it :-)


This is somewhere on my TODO list but even though hacking on Mercurial
is a lot of fun, its priority is quite low since this issue doesn't
affect me.  I'm also not entirely sure what people want -- having
separate files for every major version and an extension that merges
the news entry in the right file should also be doable.

 And do
 we really need a merged NEWS file at that granularity?

 Not really, IMO.


I'm +0 on having a separate file for 3.3, 3.4, etc., as long as I
don't have to copy/paste the news entry in the right file every time.
Anything more than that is just going to cause more troubles.

Best Regards,
Ezio Melotti

As I side note, before committing I always do an hg diff to check
that everything is OK.  Misc/NEWS is usually the last file in the
diff, so I just copy the first sentence of the entry and use it in the
commit message.

* this is also valid with Mercurial in general, but there's no need I
tell you this ;)
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Tracker settings for Peter Moody

[Ezio Melotti]

On Sat, Mar 16, 2013 at 5:18 PM, R. David Murray rdmur...@bitdance.com wrote:
 On Sat, 16 Mar 2013 15:25:56 +0100, Georg Brandl g.bra...@gmx.net wrote:
 Am 16.03.2013 15:01, schrieb Nick Coghlan:
 , we missed a step
  when granting you commit access, and it needs to be fixed so you
  appear in the Assigned To dropdown properly. (the nosy magic draws
  from the experts index instead, so it can work even if this setting is
  wrong)

 It's the 'Developer' role that puts one in the dropdown (and allows
 editing of all issue fields).  Which is why triage people appear in the
 assigned-to even though they aren't committers (yet :).


Correct.

 The committer flag only controls the icon, as far as I remember.


FTR the nosy autocomplete uses both the experts index and the list
of tracker users with the is committer flag.

Best Regards,
Ezio Melotti

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

Re: [python-committers] Anatoly Techtonik's contribution

[Ezio Melotti]

Hi,

On Tue, Jan 1, 2013 at 9:28 PM, Jesse Noller jnol...@gmail.com wrote:

 Precisely. None of us are lawyers; the CLA was made by lawyers to be
 compatible with the Python license stack which has its own set of issues.

 That all said; again, the likelihood of short term alteration of the CLA is
 a non starter, so he can feel free to take his time to understand why we
 require contributions to be licensed to the PSF under the listed licenses.

 However; I've sent this to a real lawyer for his opinion.


Since this came up again on python-dev, did you ever receive any reply
from the real lawyer?

Best Regards,
Ezio Melotti
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly Techtonik's contribution

[Ezio Melotti]

Hi,

On Fri, Dec 28, 2012 at 9:39 PM, Brett Cannon br...@python.org wrote:

 [...]
 In order to deal with this, here is my proposal that should placate those
 of us calling for a ban now and those that feel like there has not been
 enough of a warning ((I can't communicate with him because I want him
 banned and I personally don't get along with him even in person, so any
 place where someone should talk to him it can't be me in the name of
 fairness to the process):

 1. Someone emails Anatoly to tell him he is on indefinite probation for
 his behaviour where it is pointed out he can no longer insult anyone
 (including the PSF), he can't re-open issues without an explicit solution
 to the problem for why it closed, and in general has to just behave and not
 be rude

 2. We agree to point out to him nicely and calmly when he has screwed up
 and overstepped his bounds while on this probation and to record when that
 happened (an email here about any incident should be enough) so that he can
 learn from his mistakes

 3. If we do not see a pattern of improvement (this can be noticed by
 anyone and I'm sure we can get a consensus on it; unanimity is not required
 because that is impossible for anything with a group of our size), he gets
 cut off from the resource he is abusing the most and those cut-offs will
 continue on other locations if he does not improve there as well

 4. If it goes as far as he is cut off and he manages to get the point and
 behaves elsewhere he can be allowed back on to where he has been banned
 after a year has passed (IOW he has to show actual improvement)

 Three key points in this proposal. One is that he gets an official
 warning; no more side discussions with core devs, no more does he know
 people want to ban him questions as it will be clear and explicit. He will
 be flat-out told his attitude and actions are not acceptable as they stand
 and they need to change.

 Two is that there is no time limit so that he doesn't just hide away for
 e.g. six months, comes back, and then starts stirring up trouble while
 saying he behaved within the allotted time that he had to. Any change needs
 to be permanent and perpetuate forever.

 Three, the cut-offs are gradual per resource so that it isn't an
 over-arching nuclear option.

 I say Ezio lets him know that this is the plan since he talked to him
 recently and is in the no-ban-yet camp.


Yesterday I talked to him, informed him about the probation and showed him
this message.  I hope this is official enough.

We also discussed about the contributor agreement and IIUC:
 1) he signed it already 1.5 years ago but apparently it got lost (that
wouldn't be too surprising if it really happened);
 2) he thinks the current agreement is invalid because the PSF doesn't
follow the terms and requirements of the linked Apache 2 license (and while
he doesn't seem against signing in, that would be quite pointless if it was
indeed invalid);
 3) he said that an electronic signature like the one at the bottom of
http://code.google.com/legal/individual-cla-v1.0.html should be used
instead of printing/scanning/mailing the agreement (this (or some similar
suggestion) already came up a few times here).

Best Regards,
Ezio Melotti



 But even if people don't like the explicit steps as I have outlined them
 as a general rule, someone who doesn't want him banned should tell him
 flat-out that he is on thin ice as I am an admin for python-ideas and this
 plan is what I will institute starting January 1 for that list and he is on
 the top of the list of people who will be in trouble if their attitude does
 not change (I am about to email Titus about drafting up a CoC for
 python-ideas so that this applies to everyone, not just Anatoly).

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

Re: [python-committers] Anatoly Techtonik's contribution

[Ezio Melotti]

Hi,

On Tue, Jan 1, 2013 at 7:06 PM, Jesse Noller jnol...@gmail.com wrote:

 On Jan 1, 2013, at 11:54 AM, Ezio Melotti ezio.melo...@gmail.com wrote:

 Hi,

 [...]

 We also discussed about the contributor agreement and IIUC:
  1) he signed it already 1.5 years ago but apparently it got lost (that
 wouldn't be too surprising if it really happened);
  2) he thinks the current agreement is invalid because the PSF doesn't
 follow the terms and requirements of the linked Apache 2 license (and while
 he doesn't seem against signing in, that would be quite pointless if it was
 indeed invalid);
  3) he said that an electronic signature like the one at the bottom of
 http://code.google.com/legal/individual-cla-v1.0.html should be used
 instead of printing/scanning/mailing the agreement (this (or some similar
 suggestion) already came up a few times here).

 Best Regards,
 Ezio Melotti


 All of this is moot; we have a new admin; we are working towards
 electronic signatures,


That's good news.


 but it uses the same CLA as before; the terms and licenses are not
 different.

 If he refuses to sign and send in the current CLA then that's his choice,
 and his contributions will not be included.


IIUC he's also saying that a CLA doesn't necessarily require to be linked
to one or more external licenses, i.e. you can agree to contribute under
the terms of the CLA alone and that should be enough.  The Google
individual CLA seems to do this.
The problem with linking to external licenses is that *in theory* it
requires you (and him) to read, understand, and accept their terms before
putting your signature on the agreement.  In practice people are too lazy
to do it and/or they don't care, so the only common problem is that
contributors don't know which one to pick and ask you if you can lend them
a coin to flip.
So, unless there's some specific reason preventing it, it should be
possible to simplify our CLA and make it self-contained so that
contributors can easily understand what they are signing (IANAL, but it
seems to work for Google).


 If he has specific legal concerns about the CLA backed by legal standing,
 he can send them to p...@python.org and we will have legal counsel review
 them.


I think the problem (or one of the problems) is that the Apache license (
http://opensource.org/licenses/apache2.0.php) requires that, among other
things, You must give any other recipients of the Work or Derivative Works
a copy of this License; and You must cause any modified files to carry
prominent notices stating that You changed the files.  I'm not sure if we
are doing this, if we really are required to do it, and what are the
implications if we don't do it.  These are probably questions that a lawyer
should answer (but OTOH contributors should be able to understand it
without being lawyers themselves).

Also note that these issues are somewhat orthogonal.  Electronic signatures
a simpler CLA are about improving and simplifying the process, while the
issues with the Apache license could be an actual problem (that might be
solved if the external licenses are removed by the CLA).  The combination
of the two issues is probably making him uncomfortable about signing, even
if he stated that we are free to use his patches on the bug tracker as we
wish (but we can't without contribution form -- unless they are trivial).
IOW, from his point of view, he is willing to contribute, but before doing
so he has to sign the contributor form.  Since he wants to understand what
he is signing (and this is not an unreasonable request), he also has to
read and understand the linked licenses, and because there are parts of
them that are not yet clear to him, he is reluctant about signing.
(Disclaimer: the views expressed in this and some of the others email I
wrote solely represent my understanding of the issues, and do not
necessarily represent the actual views of anatoly.)

Best Regards,
Ezio Melotti
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly Techtonik's contribution

[Ezio Melotti]

On Tue, Jan 1, 2013 at 9:28 PM, Jesse Noller jnol...@gmail.com wrote:
 [...]
 I sent it to a lawyer. Note the CLA was designed by PSF legal counsel, to
 whom I have sent this thread.


Thanks for doing that!

 If he signed it 1.5 years ago, the CLA has not changed. Ergo, I fail to see
 what the issue is today.


AFAIU he's willing to sign it again -- nonetheless the issues
mentioned in my previous mail remain.

Best Regards,
Ezio Melotti
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly Techtonik's contribution

[Ezio Melotti]

Hi,

On Tue, Jan 1, 2013 at 10:57 PM, Georg Brandl g.bra...@gmx.net wrote:
 On 01/01/2013 05:54 PM, Ezio Melotti wrote:

 I say Ezio lets him know that this is the plan since he talked to him
 recently and is in the no-ban-yet camp.


 Yesterday I talked to him, informed him about the probation and showed him 
 this
 message.  I hope this is official enough.

 So, what was the reaction?  That is the important thing to know...


He acknowledged the fact, but I think he had already understood the
issue from our previous conversation.

Best Regards,
Ezio Melotti

P.S. somehow Gmail was sending HTML mails instead of plain text ones.
I now changed it back to plain text -- apologies for any inconvenience
this might have caused, and thanks to Trent for making me aware of the
problem! :)

 Georg

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

Re: [python-committers] Anatoly Techtonik's contribution

[Ezio Melotti]

Hi,

On Wed, Dec 26, 2012 at 11:07 AM, Georg Brandl g.bra...@gmx.net wrote:

 FWIW, I agree 100% with Terry here.  I'm certainly annoyed by many of
 Anatoly's
 contributions, and find myself extremely unwilling to do anything about his
 perceived issues, but to exclude a community member publicly (!) from all
 (!)
 python.org resources is going too far IMO.  Individual policy violations
 can and
 should of course be sanctioned.


I also agree with Terry and Georg.

I don't think anyone should be banned from the tracker or from the MLs
unless their actions are intentionally destructive (e.g. flooders/spammers).
This is not the case for anatoly, so in my opinion we should not take this
kind of action against him.
While I mostly lurk on python-dev/ideas, I interacted with him several
times on the bug and meta trackers, rejecting/closing a number of
suggestions/issues and accepting a few others.  I did so merely on the
value of the suggestion itself, and I can really easily ignore the tone of
the message (e.g. frustrated, angry).

That said, ISTM that the main problem is that the way he communicates is
not really effective and that results in an energy drain for other people.
This can be addressed on both the sides.
The community should ignore the tone of the messages or even the messages
themselves and most importantly avoid replies that convey the same negative
feelings.  People should be able to recognize when a discussion is not
constructive anymore and leave it, rather than wasting time just to prove a
point or to repeat themselves.  (Note that this apply to everyone, and not
to anatoly in particular).
Regarding the effectiveness of the communications there's certainty room
for improvement, but apparently the previous attempts to address the
problem were unsuccessful.  I'm willing to make an attempt myself, as I
think I have a quite clear idea of the problem.

Best Regards,
Ezio Melotti


cheers,
 Georg

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

Re: [python-committers] Anatoly Techtonik's contribution

[Ezio Melotti]

On Wed, Dec 26, 2012 at 5:07 PM, Łukasz Langa luk...@langa.pl wrote:

 Dnia 26 gru 2012 o godz. 15:09 Ezio Melotti ezio.melo...@gmail.com
 napisał(a):

  The community should ignore the tone of the messages or even the
 messages themselves and most importantly avoid replies that convey the same
 negative feelings.  People should be able to recognize when a discussion is
 not constructive anymore and leave it, rather than wasting time just to
 prove a point or to repeat themselves.


 The problem I see with that suggestion is that in reality we have to work
 with what we have, not with what we think we should have.

 I don't want to spell out names but I've had more than one discussion at
 conferences this year with people _afraid_ to get involved with core
 development on the base of having to deal with behaviour like this. In one
 case the comment was simply I don't have time to deal with [people] like
 him.


This is somewhat surprising to me.  Why would they have to deal with him?
If the people like him were the core developers I could understand the
problem, but he is just one of the many contributors.


 The other case was sadder though: Looks like you core devs have trouble
 dealing with criticism, as shown by Anatoly.


I'm not sure I understand this.  ISTM that the problem here is with core
devs, that are unable to deal with criticism (and have to resort to bans ;)
rather than with him.


 We strive to be a welcoming bunch and I'm convinced that a part of this is
 to call out anti-social behaviour and stop it. Otherwise our playground
 stops looking like a fun and safe place to contribute.


And a side effect of being welcoming is that you get every kind of people.
Different people have different behaviors and skills.  I don't think his
lack of social skills is worse than e.g. the lack of English skills of some
of the contributors.  In both cases the intentions are not bad, but the
message might be difficult to understand and thus can be misunderstood.
These people shouldn't be marginalized just because of their lack of skills.
As an example, I recently found out that one contributor on the tracker
that sounded somewhat annoying actually was a ~10 years old kid.  From that
point of view his contributions went from somewhat annoying to quite
impressive (and I think some of his patches have been committed too).
Of course if people have an intentionally destructive behavior they can be
stopped.


 This is not elitism nor censorship but a simple manner of respecting each
 other. Think: out of respect for Guido's (or other senior devs') time


I heard this argument several time, but I'm not sure it's a really strong
one.  No one is forced to spend his time in any specific way.  Granted, as
a contributor you end up spending some of your time for this kind of things
as well, but that also includes skimming through mails/comments that you
don't care about, tell people that they wrote to wrong ML, that the issue
they reported is invalid and so on.
If people spend time reading his messages and responding to him, I assume
they have reasons to do it.  If this turns out to be ineffective they
should stop.


 we should put an end to this. Judging from the YouTube view count,
 humanity has spent over 3000 years watching Gangnam Style. How much time
 did humanity spend on this thread and all other non-constructive
 threads/issues fired by Anatoly?


This is not necessarily non-constructive.  We have identified a problem and
we are discussing about the possible ways it can be solved, while learning
how to deal with similar problem should they occur again in the future.

Best Regards,
Ezio Melotti

P.S. I haven't seen Gangnam Style yet -- I'm too busy tweaking rst markup
in the docs :)


 --e.g.
 Best regards,
 Łukasz Langa


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

Re: [python-committers] Anatoly Techtonik's contribution

[Ezio Melotti]

On Wed, Dec 26, 2012 at 4:18 PM, Brian Curtin br...@python.org wrote:

 You're wasting your time if you think you will be the one to break
 through to him after several people have already talked to him.
 Apparently he even got on Skype with Guido about this. People would
 *pay* to have that chance. Anatoly got it for being a jerk and it
 changed nothing.


So, I contacted him and we chatted for about an hour.
He said that he's been trying to pay more attention and improve his
messages lately.
We went through a list of problems and he was willing to listen (he
actually seemed more polite than I expected).
He also seemed somewhat frustrated by the fact that his messages are taken
in a negative way, because he doesn't mean to be negative.
I also went through his recent messages on the tracker to find negative
examples but admittedly they mostly seem OK, so I wonder if our opinion
towards him is already negatively biased and leads us to be less tolerant
with him
At the end he thanked me for bringing this up with him, and apparently he
is willing to improve.

Best Regards,
Ezio Melotti
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly Techtonik's contribution

[Ezio Melotti]

On Wed, Dec 26, 2012 at 7:37 PM, R. David Murray rdmur...@bitdance.comwrote:

 On Wed, 26 Dec 2012 18:20:06 +0200, Ezio Melotti ezio.melo...@gmail.com
 wrote:
  On Wed, Dec 26, 2012 at 5:07 PM, Łukasz Langa luk...@langa.pl wrote:
   I don't want to spell out names but I've had more than one discussion
 at
   conferences this year with people _afraid_ to get involved with core
   development on the base of having to deal with behaviour like this. In
 one
   case the comment was simply I don't have time to deal with [people]
 like
   him.
 
  This is somewhat surprising to me.  Why would they have to deal with him?
  If the people like him were the core developers I could understand the
  problem, but he is just one of the many contributors.

 Because, to put it in new age-y terms, his bad vibrations are poisoning
 the environment.


I considered this but probably underestimated it -- after all there are
many other contributors that produce enough good vibrations.
My skewed perception might be due to the fact that I don't contribute
actively to the python-dev/ideas MLs.


 That is perhaps a graphic way to put it, but it is a matter of community
 tone and nurturing a joyful and creative environment in which all are
 welcome and feel encouraged to contribute.

 Anatoly works against that, almost constantly.  Encouraging him to
 support the community would be *much* better than banning him...but
 we've tried that.

   The other case was sadder though: Looks like you core devs have
 trouble
   dealing with criticism, as shown by Anatoly.
  
  I'm not sure I understand this.  ISTM that the problem here is with core
  devs, that are unable to deal with criticism (and have to resort to bans
 ;)
  rather than with him.

 By not understand, I presume you mean the sadder comment.

 It is not that we are *unable* to deal with criticism.  We have dealt
 reasonably with every criticism he has leveled, I think.  But his comments
 create the *perception* that we are not dealing well with criticism,
 because he is not but casts the aspersion onto us, while we do that much
 less frequently to him, but do occasionally lapse into returning tit
 for tat.  Since we are perceived as the ones in the position of power,
 we get castigated for our actions and reactions much more than Anatoly,
 the one perceived to be powerless in the situation, ever will be.

 Let me repeat that bit, it is important.  We are perceived as being the
 ones in the position of power, and he the powerless.  That perception
 (and the reality behind it) will color every conversation that the wider
 community has about this issue.  That is why I stress that our position
 and our actions have to come from well articulated principles, otherwise
 they will be perceived as caprice.

 Which, I think, is more or less why you are arguing we should not
 take action.


Good point, and that's indeed one of the reasons why I'm against taking
actions.
If we do people might get scared away because they don't want to be banned
or because they think we are not open to criticism or new ideas.


 However, dealing reasonably with him gets harder and harder over time.
 It is a failing in me as a person, but every time I see a message from
 Anatoly, my gut clenches up and I go into a defensive mode, and want to
 prove him wrong.


Knowing this, I actually try to see if there's something good in his
suggestions so that they don't get overlooked by devs that are ignoring him
(that depends on the issues though).


  So I have to master myself and try to speak reasonably,
 and try to not give back to him what he gives to us.  I hope I'm getting
 better at that, but...


That's laudable, and I wish everyone else would do that.


 Take issue 16781 as a recent example.  I wanted to prove him wrong,
 both because of his past actions and because of my perception (probably
 colored by those past actions) of his choice of title for the issue
 (execfile/exec messes up...)  But there is a real (documentation)
 issue there.


We discussed about that, but unfortunately I missed the original title.
My criticism (albeit mild) was about the use of the word magical(ly) that
seems to imply that the behavior of Python is magical and obscure.
He said that from his point of view the behavior looked magical, and I
don't think he meant it as a non-constructive criticism against Python.


  I managed to moderate my tone...almost.  I still failed:
 I said the fact that the print works should be a clue, implying that
 he should have seen it himself, But if I were dealing with anyone else,
 I would have said, The fact that the print works is a clue...

 This difference is *subtle*.  But those subtleties are *important* in
 determining the tone of a community, the supportiveness of a community,
 the openness of a community, the inclusiveness of a community.  Someone
 reading my comment on that bug without knowing Anatoly's history would
 think that the Python community is very stuck up.  It is so easy

[python-committers] Commit privileges for Chris Jerdonek

[Ezio Melotti]

Hi,
I would like to propose Chris Jerdonek as a new core developer.
His first contribution dates back to April 2010, and since then he
report several issues and contributed many quality patches.
He has also already signed the contributor agreement, and he is
interested in becoming a core developer.

Best Regards,
Ezio Melotti
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Django running in debug mode on bugs.python.org

[Ezio Melotti]

On Tue, Aug 14, 2012 at 8:32 AM, Alexandre Vassalotti
alexan...@peadrop.com wrote:
 Hi guys,

 I just got an exception from the code review tool running on
 bugs.python.org. The server returned the full debug stack trace (which means
 DEBUG=True in Django). Is this intended?

 Cheers,
 -- Alexandre

It used to be set to True but IIRC at some point I changed it to be False.
Unless someone changed this intentionally, it's likely that the change
got lost when the repo got moved to HG.

Best Regards,
Ezio Melotti
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Three wishes for Mercurial-Roundup integration

[Ezio Melotti]

Hi,

On 02/09/2011 19.53, Éric Araujo wrote:

Le 31/08/2011 20:13, Georg Brandl a écrit :

1) When a commit message references more than one bug (with text
matching #\d+), only the first gets a message for the changeset.  I
would like all referenced bugs to get a message.

+1.  Just make sure that only issues that should be closed are closed
(i.e. if the commit message is Close #1234: better fix than proposed
in #5678, #1234 should be closed, and #5678 get a reference).

You, Nick and Terry are +1, Ezio -1.  I originally changed my mind and
agreed with Ezio after discussing it on IRC, on the basis that duplicate
bug should be sorted out in the tracker, but the majority here is in
favor.  I’ll wait a bit for other opinions.


Clearly with -1 I meant wishes -= 1, since now even this last one 
should be fixed ;)

(http://hg.python.org/hooks/rev/ebdd1c1c365b)

Best Regards,
Ezio Melotti
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Commit rights for Petri?

[Ezio Melotti]

On 21/10/2011 20.13, Antoine Pitrou wrote:

Hello,

Petri Lehtinen has been an active contributor for some time, he has been
quite receptive to reviews and we have committed a dozen of his patches.
Do you think it is time to offer him commit rights?


+1
I also met him during the sprints at PyCon FI and he was the most active 
contributor of the group.


Best Regards,
Ezio Melotti



cheers

Antoine.


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

Re: [python-committers] Commit rights for Meador Inge

[Ezio Melotti]

On 19/09/2011 5.11, Meador Inge wrote:

On Sun, Sep 18, 2011 at 6:03 PM, Brett Cannonbr...@python.org  wrote:

http://docs.python.org/devguide/coredev.html#gaining-commit-privileges

I believe everything is in place:

1. I am subscribed to the right mailing lists.
2. I already had the Developer role in the tracker.
3. I changed my tracker username from 'meadori' to 'meador.inge'.
4. I sent my SSH key to Georg and he set me up with repo access,
which I tested on http://hg.python.org/test/.
5. I faxed my contributor agreement on Saturday.

My tracker details need to be changed to committer, though.  How do I that?


Done.
Pat will probably take care of updating the contributor form received 
field as soon as she receives the contributor agreement.
Even if it's not mentioned on the devguide, if you use IRC, you might 
want to join the #python-dev channel on irc.freenode.net.  There you can 
get real-time updates about commits, new messages posted on the tracker, 
the buildbots status, and you can also get in touch with other developers.


Best Regards,
Ezio Melotti



-- Meador
___
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] Three wishes for Mercurial-Roundup integration

[Ezio Melotti]

Hi,

On Wed, Aug 31, 2011 at 5:39 PM, Éric Araujo mer...@netwok.org wrote:

 Hi,

 1) When a commit message references more than one bug (with text
 matching #\d+), only the first gets a message for the changeset.  I
 would like all referenced bugs to get a message.


I'm -0 on this. Even if it shouldn't be too difficult to implement I'm not
sure it's worth doing it, since it's not something that happens often enough
and when it does you usually want to explain something more to the second
issue anyway.  Moreover fixes should be related to a single issue.


 2) When a bug number (#\d+) is not in the first line of the commit
 message, no message is sent.  Is there a reason for this or is it a bug?
  (Note: I’m not sure about this one, I may misremember.)


From a quick look at the code I don't see any obvious reason why this
shouldn't work, if it really doesn't I guess it can be fixed.  (I prefer to
always write the issue number at beginning of the line though.)


 3) To let us track the backport of changesets from cpython/packaging to
 distutils2, I would like the script to look at changesets in the
 distutils2 repo and send messages to Roundup when a bug number is detected.


It would be useful for the devguide repo too, now that we have a 'devguide'
component (and possibly for 'benchmarks' too, as you suggested on
#python-dev).


 Thanks in advance


Best Regards,
Ezio Melotti
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Committer rights for Sandro Tosi

[Ezio Melotti]

Hi,

On 03/08/2011 3.29, Pat Campbell wrote:

Hi Ezio:

Okay, and yes, please have Sandro submit a contributor agreement.


He should have sent it already yesterday morning, via fax.

Best Regards,
Ezio Melotti



Thanks,
Pat



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

Re: [python-committers] Committer rights for Sandro Tosi

[Ezio Melotti]

On 01/08/2011 17.00, R. David Murray wrote:

On Sun, 31 Jul 2011 19:53:00 +0300, Ezio Melottiezio.melo...@gmail.com  wrote:

I would like to have Sandro added to the list of committers.
He has been very active on the bug tracker, doing triaging work and
contributing a number of patches.
He also reported more than 40 issues, mainly about the documentation,
and most of them have been fixed.

Given Sandro's level of activity and the (at least for the ones I've
looked at, which granted haven't been many) accuracy of his doc patches,
I think he would be a valuable to have as a committer.  From my
interactions with him I don't think we need to have any worry about
his going crazy with code commits...he's very aware of the need
to be conservative and get reviews.

Ezio, are you volunteering to be his mentor?  If so, then definitely +1.


Sure.

Best Regards,
Ezio Melotti



--
R. David Murray   http://www.bitdance.com



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

[python-committers] Committer rights for Sandro Tosi

[Ezio Melotti]

Hi,
I would like to have Sandro added to the list of committers.
He has been very active on the bug tracker, doing triaging work and 
contributing a number of patches.
He also reported more than 40 issues, mainly about the documentation, 
and most of them have been fixed.


He hasn't submitted the contributor agreement yet but he will do it as 
soon as he finds a printer/scanner/camera/fax.


Best Regards,
Ezio Melotti
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Jean Paul-Calderone Commit Access

[Ezio Melotti]

On 05/04/2010 16.56, Michael Foord wrote:

Hello all,

I would like to propose Jean-Paul Calderone (exarkun) for commit access.

He is a core-twisted developer and a very experienced Python developer 
with a passionate belief in good testing. He also regularly comments 
the issue tracker. Twisted run their test framework against 
python-trunk, so he often reports compatibility issues they discover.


Patches he has already submitted include those on issues 658327, 5767, 
6844, 5485 and 639307.


I would be very happy to 'mentor' him, but don't think I qualify as I 
wouldn't be able to check C patches. He knows the Python workflow well 
enough though.


All the best,

Michael Foord



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