[python-committers] Re: Making it easier to track who is currently considered "active" for voting

2020-10-23 Thread M.-A. Lemburg
FYI: There's a ticket open to address the remaining missing parts of the
process that is defined in PEP 13 vs. the what the voting script
implements:

https://github.com/python/voters/issues/16

I've implemented some extra logic to enable tracking the inactivity
status as per PER 13 and creating a file which can be used for the
notification emails, which are needed to convert a core dev's status
to inactive:

https://github.com/python/voters/pull/25

I'd like to get this merged before the next vote and can also volunteer
to take care of sending out the notification emails, unless the SC
or the voting managers want to do this.

As part of implementing the change, I noticed that even considering
the new "left" field Brett added, we are missing quite a few status
checks from core developers. The next vote should remedy this by
adding the missing fields with the notification status and get us
back on track with respect to PEP 13.

With the extra tooling in place, it would also be worthwhile to consider
defining the notification process for how to use the tool and
documenting it in the README.md.

The above tickets already have some ideas.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Oct 23 2020)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/

On 20.10.2020 21:16, Brett Cannon wrote:
> With the next SC election fast approaching, I did the final tweaks I wanted to
> make to the voters repo to address visibility issues we had in the last 
> election.
> 
> First, there is now a monthly cron job that will run at
> https://github.com/python/voters/actions?query=workflow%3A%22Projected+Voter+Roll%22
> which will project a Dec 01 vote and then calculate who would fall off the 
> voter
> roll based solely on activity, who would be added, and then the full list of
> voters. What that means is the two year of activity is calculated back from 
> the
> next Dec 01, so you can check to see if you haven't committed or authored code
> in that timeframe to automatically be put on the voter roll.
> 
> Second, I created
> https://github.com/python/voters/actions?query=workflow%3A%22Generate+Voter+Roll%22
> for manually creating the voter roll. This means people can manually trigger 
> the
> same code used to create the initial voter roll and see who would (not) be
> automatically placed on it. I expect this to mostly be used by the folks 
> running
> the election. And I do advise specifying the full date as the input instead of
> using the MM-DD shortcut if you choose today as it will most likely wrap 
> around
> to projecting a vote next year.
> 
> Finally, I updated the data to include when someone left the core team (and if
> someone was ejected, which is a term from PEP 13). For those that never 
> entered
> a GitHub username, I implicitly put them as having left the team the day the
> first PR was merged on GitHub since they stopped being able to participate
> actively from that day forward with an appropriate note as to why 
> (2017-02-10).
> This is now shown in the developer log at 
> https://devguide.python.org/developers/.
> 
> Hopefully this is enough to easily check if one should try to get a quick PR
> committed and/or authored before an election. We can all also try to remember 
> to
> include it in the vote announcement email going forward if anyone forgets.
> 
> ___
> python-committers mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/[email protected]/message/DLJE25TWAQ2KBGVJUSUO4W7KSZYHFFVC/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
> 
___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/XXYKCLQK7NYCFP35FJD6J7XEH27BQWLQ/
Code of Conduct: https://www.python.org/psf/codeofconduct/


[python-committers] Is adding an email package "defect" a new feature?

2020-10-23 Thread Barry Warsaw
Over in:

* https://bugs.python.org/issue30681
* https://github.com/python/cpython/pull/22090

Georges Toth has a PR that fixes some problems with 
email.utils.parsedate_to_datetime().  I like the PR, and am ready to approve it 
for 3.10.  Georges would like it back ported, which I would be normally be okay 
with *except* that it adds a new “defect” class.

Defects are a way for the email parser to indicate problems with the incoming 
data without throwing an exception.  This is an important constraint because we 
never want clients of the parser to have to deal with exceptions.  So if e.g. a 
message had some formatting or syntactic problem, but was otherwise parseable, 
you’d still get an email object back from the parser, but attached to it would 
be a list of defects that were encountered.  Clients then could choose to 
ignore or handle these defects depending on the use case.  Defects are 
implemented as classes that get instantiated with some useful information and 
appended to an email message’s “defects” list.

PR #22090 adds an InvalidDateDefect for cases where parsing the Date: header 
encounters problems, such as an invalid hour value.  I think this is the right 
thing to do to fix the reported bug, but I am on the fence as to whether this 
new defect class should prevent back porting.  OT1H, it can’t break existing 
code, but OTOH this defect will only be found when run in Python bug fix 
releases with the new defect detection.

What do you think?  And especially, what does Łukasz think, since he’s the RM 
for back port candidates 3.8 and 3.9?

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/RXUMNWKIILG2WKUNL6DAYAQ42VO7AU6D/
Code of Conduct: https://www.python.org/psf/codeofconduct/