Re: [python-committers] Reminder of BDFL succession timeline + CFP
On Thu, Aug 02, 2018 at 09:22:44AM +0100, Paul Moore wrote: > On Thu, 2 Aug 2018 at 08:50, Steven D'Aprano wrote: > > > Indeed. A hard deadline concentrates the mind. It doesn't need to be > > tomorrow, I think your choosen dates are a great balance, neither too > > quick nor too drawn out. > > But it also encourages people (particularly people with limited free > time) to rush decisions, and focus on "getting something done in > time", rather than "doing the right thing". Balancing those two > pressures is not easy, and the balance point varies significantly > between individuals. A proposal is not an agreement to accept that proposal. If people submit rushed, poor quality proposals, they will likely not be accepted. And if they are, we have nobody to blame but ourselves. Can't blame Facebook and fake news if we vote badly :-) The longer we push out any such deadline, the more likely people will simply forget about it, or delay until the week before and then have to rush a poorly delivered proposal (or no proposal at all). > > If Python is still rudderless by Christmas, I think we have failed. > > Do you really consider Python "rudderless" at the moment? *shrug* I'm not married to that specific word, but we have no BDFL and no mechanism in place for making big decisions about the language. What term would you use? Certainly day to day development continues as normal. Bugs get fixed, minor releases get released, PRs get reviewed, etc. That's great and a credit to the core developers. But this thread suggests that if we're not careful, we could get bogged down for many months just deciding on the mechanism we use to decide what to do next. That's why I like Mariatta's concrete proposal to set some firm dates for action. In my opinion, if people can't find an hour or four to write up a concrete proposal for choosing a new Dictator/Despot/Council/whatever in eight weeks, they're not likely to find the time/motivation in eight months either. > I honestly think that describing the current situation as "rudderless" > and a "failure" if it carries on, is a pretty big exaggeration. Christmas is almost five months away. Do you think that it is acceptable for such a small group as us to take five months and still not have decided on a new leadership model? That's a matter of personal opinion and I accept we can differ on tolerance for bikeshedding. How many months, or years, before you personally would call it a failure? When Australia's prime minister disappeared, it took two days to swear in a replacement and less than a month to call a new election. https://en.wikipedia.org/wiki/Harold_Holt#Disappearance Obviously the stakes are higher for national governments, we can afford to be more leisurely about the process, but I don't think we should let it drag on and on. I think that Christmas is more than sufficient. If you don't, how long do you feel will be? This isn't a rhetorical question. I'm not wedded to this time frame -- if you think we need six months, I'm listening. If you think we need six years, forget it :-) It's been three weeks since Guido's retirement, approaching a month. We agree that we need some sort of leadership model, and we know that there's a risk of the process devolving into endless argument with no progress, or just fading away into inactivity, unless managed. In my opinion agreeing on concrete deadlines, not too rushed but certainly not too far away either, is a good first step at managing this. -- Steve ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] View logs on VSTS?
That looks unrelated. In this case I’m guessing the test run timed out and Ctrl+C failed to terminate it. For some reason when that happens the logs for the item that timed out are not shown, I'd guess because the item is marked “Timeout” rather than “Failed”. Do you see the “download logs” button? And does that contain the logs? It’s a pain, but totally locked up tests like that should be rare… Top-posted from my Windows 10 phone From: Victor Stinner Sent: Thursday, 2 August 2018 10:03 To: Antoine Pitrou Cc: python-committers Subject: Re: [python-committers] View logs on VSTS? Hi, The error may be related to https://bugs.python.org/issue33782 I understood that VSTS has troubles when a PR gets a new commit while VSTS is running tests on the previous commit. Victor 2018-08-02 0:00 GMT+02:00 Antoine Pitrou : > > Hello, > > I may be missing something, but I fail to view the "tests" log in this > failed CI build: > https://python.visualstudio.com/cpython/_build/results?buildId=20701&view=logs > > Regards > > Antoine. > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/ ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] List of all core developers
On Fri, Aug 3, 2018, 21:59 Donald Stufft, wrote: > > > On Aug 3, 2018, at 1:52 PM, Brett Cannon wrote: > > > > On Fri, 3 Aug 2018 at 00:44 Donald Stufft wrote: > >> We should probably have a single source of truth for what a core >> developer is, and all other systems pull from that. >> > > Ah, but I think there might be a terminology clash here. Using MALs > definition means that you can be a core developer but not have commit > privileges due to relinquishing those privileges at some point. So I'm not > sure what systems you are referring to that need to know if someone > historically happened to be a core developer. > > > We have that I am aware of right now: > > - GitHub > - bugs.p.o > - python-committers > > And it sounds like Marc-Andre is looking to add to it: > > - A third party/user facing list of developers, regardless of the > technical status of their ability to commit (e.g. even if they don’t have a > GitHub account). > > > There may be other systems that I can’t recall off the top of my head (is > anything still in hg.python.org? I dunno). > For us, hg.python.org only has the b.p.o code. > As of right now, I believe the list of who a core developer is and has > historically been somewhat adhoc based upon who has permissions to commit > things. > Yep. Meaning that as we transition from one system to another we “lose” the > ability to account for people over the years. This would also make it > harder for someone to come back, because they’d have to track down someone > who knew they were a core developer (and let’s be honest, human memory > sucks so sometimes you’re just not sure if someone was or wasn’t). > Yes, us old-timers aren't perfect. 😉 If someone couldn't remember we would probably go into the mailing list archives. > So I think it would probably be a good thing if we had one central > location that answers the question of who is and isn’t a core developer, > that isn’t tied to the ACLs of one particular system that we happen to be > using today. Ideally these other related systems (bugs.p.o, Github, etc) > are then modified to pull from this thing as the singular source of truth. > This could be as simple as a CSV/tom/yaml file sitting in a repository > somewhere that lists all of the developers, their status etc, plus scripts > that will synchronize access from that to the relevant places. > It would probably sit in the devguide. The question is how to potentially display this in a readable format? Or maybe we don't care as long as we use a format that makes both humans and computers happy? Otherwise we would have to add a build step to the site. (Personally I say we do it in TOML since it's readable and can still be writable through the GitHub web UI since I am typically the person adding new folks 😁; we can then just link to it for people to peruse.) > So for arguments sake, it could be a CSV file with the schema: > > Name, Email, Active, bugs.p.o Username, GitHub username > I would toss into the year joined. I know over in the GitHub issue about this topic that people also don't want to lose mentor/voucher/proposer and any notes about why the person got their commit privileges. > And then a script that could be ran whenever that would check the > permissions of the GitHub team for CPython, and ensure that anyone listed > there has been added to the GitHub team (and probably anyone who isn’t, has > been removed, to ensure that getting in this file is the _way_ you get > access). Likewise bugs.p.o could pull from this, and Marc-Andre’s public > facing list could as well. > > Of course we can get fancier than a simple file somewhere, the key thing > is that there is a single source of truth, that isn’t tied to one > particular service or tool that we use (unless that tool is dedicated to > managing this list of people), because anytime we tie maintaining this list > of people to the technical aspects of giving someone an ACL to a particular > system, then our list is going to become outdated anytime we switch systems > (and some % of people won’t ever make the jump to the new system). > > > Assuming what you mean is people with commit privileges, then we have the > "lovely" complication of usernames being inconsistent for people across > systems which is probably what is required to make any centralized list > useful for systems to interact with. We could solve this by using a table > instead of a list for people to list e.g. their GitHub and b.p.o usernames > if people wanted to go that route. > > >> >> > On Aug 3, 2018, at 3:43 AM, M.-A. Lemburg wrote: >> > >> > Please note that the motivation for having a list similar to the >> > one we have for PSF Fellows is not to determine voting eligibility. >> > >> > This is about having a record of the core developer status available >> > to show to 3rd parties, e.g. to (potential) employers, organizations, >> > government agencies, etc. >> > >> > Having a place to also record the email addresses for internal >> > use s
Re: [python-committers] List of all core developers
Yea to be clear. I just used csv and those fields as an example. I think TOML is a better choice, and we can add whatever fields are useful. Part of the devguide build step could be turning that into a nice human facing list (does that satisfy what Marc-Andre is looking for?). We could also have a cronjob that syncs github permissions with that list. Sent from my iPhone > On Aug 4, 2018, at 12:51 PM, Brett Cannon wrote: > > > >> On Fri, Aug 3, 2018, 21:59 Donald Stufft, wrote: >> >> >>> On Aug 3, 2018, at 1:52 PM, Brett Cannon wrote: >>> >>> >>> >>> On Fri, 3 Aug 2018 at 00:44 Donald Stufft wrote: We should probably have a single source of truth for what a core developer is, and all other systems pull from that. >>> >>> Ah, but I think there might be a terminology clash here. Using MALs >>> definition means that you can be a core developer but not have commit >>> privileges due to relinquishing those privileges at some point. So I'm not >>> sure what systems you are referring to that need to know if someone >>> historically happened to be a core developer. >> >> We have that I am aware of right now: >> >> - GitHub >> - bugs.p.o >> - python-committers >> >> And it sounds like Marc-Andre is looking to add to it: >> >> - A third party/user facing list of developers, regardless of the technical >> status of their ability to commit (e.g. even if they don’t have a GitHub >> account). >> >> >> There may be other systems that I can’t recall off the top of my head (is >> anything still in hg.python.org? I dunno). > > > For us, hg.python.org only has the b.p.o code. > >> >> As of right now, I believe the list of who a core developer is and has >> historically been somewhat adhoc based upon who has permissions to commit >> things. > > > Yep. > >> Meaning that as we transition from one system to another we “lose” the >> ability to account for people over the years. This would also make it harder >> for someone to come back, because they’d have to track down someone who knew >> they were a core developer (and let’s be honest, human memory sucks so >> sometimes you’re just not sure if someone was or wasn’t). > > > Yes, us old-timers aren't perfect. 😉 If someone couldn't remember we would > probably go into the mailing list archives. > > >> >> So I think it would probably be a good thing if we had one central location >> that answers the question of who is and isn’t a core developer, that isn’t >> tied to the ACLs of one particular system that we happen to be using today. >> Ideally these other related systems (bugs.p.o, Github, etc) are then >> modified to pull from this thing as the singular source of truth. This could >> be as simple as a CSV/tom/yaml file sitting in a repository somewhere that >> lists all of the developers, their status etc, plus scripts that will >> synchronize access from that to the relevant places. > > > It would probably sit in the devguide. The question is how to potentially > display this in a readable format? Or maybe we don't care as long as we use a > format that makes both humans and computers happy? Otherwise we would have to > add a build step to the site. (Personally I say we do it in TOML since it's > readable and can still be writable through the GitHub web UI since I am > typically the person adding new folks 😁; we can then just link to it for > people to peruse.) > >> >> So for arguments sake, it could be a CSV file with the schema: >> >> Name, Email, Active, bugs.p.o Username, GitHub username > > > I would toss into the year joined. I know over in the GitHub issue about this > topic that people also don't want to lose mentor/voucher/proposer and any > notes about why the person got their commit privileges. > >> >> And then a script that could be ran whenever that would check the >> permissions of the GitHub team for CPython, and ensure that anyone listed >> there has been added to the GitHub team (and probably anyone who isn’t, has >> been removed, to ensure that getting in this file is the _way_ you get >> access). Likewise bugs.p.o could pull from this, and Marc-Andre’s public >> facing list could as well. >> >> Of course we can get fancier than a simple file somewhere, the key thing is >> that there is a single source of truth, that isn’t tied to one particular >> service or tool that we use (unless that tool is dedicated to managing this >> list of people), because anytime we tie maintaining this list of people to >> the technical aspects of giving someone an ACL to a particular system, then >> our list is going to become outdated anytime we switch systems (and some % >> of people won’t ever make the jump to the new system). >> >>> >>> Assuming what you mean is people with commit privileges, then we have the >>> "lovely" complication of usernames being inconsistent for people across >>> systems which is probably what is required to make any centralized list >>> useful for s
Re: [python-committers] View logs on VSTS?
Le 04/08/2018 à 18:19, Steve Dower a écrit : > That looks unrelated. > > In this case I’m guessing the test run timed out and Ctrl+C failed to > terminate it. For some reason when that happens the logs for the item > that timed out are not shown, I'd guess because the item is marked > “Timeout” rather than “Failed”. > > Do you see the “download logs” button? And does that contain the logs? > It’s a pain, but totally locked up tests like that should be rare… I can download the logs, but the archive doesn't contain any logs for the failed step (the one that timed out). Regards Antoine. ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
