Re: archive this group & redirect conversation elsewhere?

[Xavier Fernandez]

Fine with me :)

On Sun, 10 May 2020 at 12:45, Sumana Harihareswara <
sumana.hariharesw...@gmail.com> wrote:

> Hey all -- I've heard no opposition, onlist or offlist. As I asked in
> April: please speak up if I'm wrong, or if there's some other reason to
> keep this Google group going. And please reply if you agree with the idea -
> Jason's the only one who's replied so far.
>
> Reply by May 12th (2 days from now).
>
> -Sumana
>
>
> On Friday, May 1, 2020 at 6:02:16 PM UTC-4, Sumana Harihareswara wrote:
>>
>> Thanks, Jason.
>>
>> Nudge to the group; 11 more days to comment.
>> -Sumana
>>
>> On 4/14/20 9:20 PM, Jason R. Coombs wrote:
>> > My initial reaction was that I _need_ this list, but after a moment’s
>> consideration, I think you’re right. +1
>> >
>> >> On 13 Apr, 2020, at 22:18, Sumana Harihareswara  wrote:
>> >>
>> >> TL;DR: ok to archive this Google group? Reply by May 12th.
>> >>
>> >> Below: Context and proposal, reasoning, and timeline.
>> >>
>> >>
>> >> Context & proposal:
>> >>
>> >> People talk about Python packaging problems, work, and plans in many
>> different media: https://discuss.python.org/ , distutils-sig, blogs,
>> Twitter, conference talks, IRC, https://python.zulipchat.com/ ,
>> individual GitHub issues on several different repositories, Stack Overflow,
>> and more. So people frequently ask me: where should I go to keep up, or to
>> announce something or ask for feedback? It's hard to guide them, because of
>> this proliferation and fragmentation. And people have commented on that
>> before, both senior folks like Donald[0], and people who are earlier in the
>> learning curve[1].
>> >>
>> >> We can't and shouldn't stop people from talking about Python packaging
>> on social media, at conferences, and so on. But three mailing lists/forums
>> on nearly identical topics strikes me as more than we need.
>> >>
>> >> So I suggest that, one month from now, we stop posting to this list (
>> pypa-dev@googlegroups.com) and essentially archive it.
>> >>
>> >>
>> >> Reasoning (why close THIS one?):
>> >>
>> >> We now have three mailing list-type places to talk about Python
>> packaging tools and progress. All of them allow both reading and posting
>> from the web or from an email client, and all of them have web archives
>> with built-in search. Generally, the people who want to talk about one of
>> these topics want to hear about the same topics (things happening in PyPA
>> and about related things in Python that will affect PyPA) no matter what
>> venue they're in.
>> >>
>> >> 1. pypa-dev (here). Started in 2013. About 5 posts in the past month,
>> mostly cross-posted to other places as well. Hosted by Google in a
>> closed-source application that doesn't seem to get much love from Google's
>> product folks.
>> >>
>> >> 2. The distutils-sig mailing list[2] which has expanded in its scope.
>> It's a place to discuss and resolve problems that cut across different
>> parts of the Python packaging ecosystem, and to announce new releases or
>> in-progress work. You can log in an account, or with Facebook, GitHub,
>> GitLab, or Google authentication. About 12 threads in the past month.
>> Hosted by Python Software Foundation with an open source application that's
>> under active development.
>> >>
>> >> 3. The Packaging category on Python's Discourse forum
>> https://discuss.python.org/c/packaging , which started about a year and
>> a half ago[3]. Very wide scope. You can log in with an account, or with
>> Facebook or GitHub or via email. About 21 posts per month. Hosted by PSF
>> with an open source application that's under active development.
>> >>
>> >> Maybe I'm missing something. Maybe there is a function being served by
>> having a mailing list that is specifically labelled "PyPA" (for instance,
>> we could add "get on the Google Group and that makes you a member of PyPA"
>> to the pypa.io docs[4]). Maybe there are people actively reading/posting
>> here who feel unwelcome on the other two lists/forums, because of
>> atmosphere or user interface. As a person doing a bunch of work on PyPA
>> stuff over the past ~2.5 years, I haven't noticed either of those
>> conditions, so please speak up if I'm wrong, or if there's some other
>> reason to keep this Google group going.
>> >>
>> >>
>> >> Timeline and methods:
>> >>
>> >> Here's what I suggest, and what I will carry out if there is no
>> objection.
>> >>
>> >> In one month, on May 13th, I would verify that no one has argued here
>> for why this Google group should continue to be open for posting. Or, even
>> if a few people have objected to closing the list, I would check for rough
>> consensus, especially of people who are doing SOMETHING productive having
>> to do with PyPA (teaching, answering questions online or in person, running
>> key infrastructure, writing documentation, making or fixing software,
>> etc.).
>> >>
>> >> I would post a final message to this list, marking its close and
>> suggesting that people use distutils-sig or 

Re: New pip core developer: Pradyun Gedam

[Xavier Fernandez]

Welcome Pradyun !

Glad to have you onboard :)

On Thu, Oct 5, 2017 at 10:51 PM, Paul Moore  wrote:

> Many of you will have seen the work Pradyun has been doing on the pip
> tracker recently. He's been doing a fantastic job, and as a result,
> we've offered him core developer status - and I'm pleased to say that
> he's accepted :-)
>
> Welcome, Pradyun - thanks for all the work you've been doing, and
> here's to plenty more ;-)
>
> Paul
>

Re: Remove access from inactive maintainers

[Xavier Fernandez]

Fine with me also and xafer is my username.

On Tue, Jun 6, 2017 at 12:24 AM, Paul Moore  wrote:

> On 5 June 2017 at 23:05, Donald Stufft  wrote:
> > Absent any objections, I’ll take these actions in the next couple of days
> > (and I’ll need PyPI usernames for Paul and Xavier).
>
> Fine with me (my PyPI username is pf_moore).
> Paul
>

Re: GSoC, Pradyun, and Us

[Xavier Fernandez]

Yup, and a lot of good work has already been made and merged :)
Welcome again !

On Fri, May 19, 2017 at 1:07 PM, Paul Moore  wrote:

> On 19 May 2017 at 11:58, Donald Stufft  wrote:
> > I just occurred to me that I don’t think we ever announced it or made it
> > official here.
> >
> > You might have noticed Pradyun making some PRs lately, he’s been
> accepted as
> > a GSoC student working on pip. Right now he’s in the “Community Bonding”
> > period which is really just about diving into the project, getting
> > aquatinted with the project and with the people before he starts really
> > working on his project. Pradyun has been around for a bit and has already
> > submitted a number of PRs and helped to get the upgrade strategy work
> across
> > the finish line.
> >
> > The project that he’ll be working on is fixing #988, which as I’m sure
> > you’re all aware is one of our biggest open issues and gets implicated in
> > problems end users experience fairly regularly. You can see his final
> > proposal for this work at
> > https://gist.github.com/pradyunsg/5cf4a35b81f08b6432f280aba6f511eb.
> >
> > I am super excited to have Pradyun helping us, and I think it’s going to
> be
> > great to finally get #988 solved!
>
> Agreed, this is really great - welcome Pradyun!
>
> Paul
>

Re: Automation and other changes

[Xavier Fernandez]

First of all, thanks a lot for all the work you've put in pip, especially
lately.

Like Paul, I rely mostly on mail notifications to follow new/updated
issues/PR.
I usually read everything and if I don't respond immediately, I'm used to
leaving the mail as unread to - hopefully - come back to it later (it does
not work so well, since I've currently 238 unread mails in my Github/pip
label ;) ).
I'm not particularly satisfied with this workflow (even if it globally
works), so any improvement is very welcome.

Between the different options A (dismiss review on update), B (dismiss
review on contributor special message) and C (nothing), I think B has my
favor, (followed by A and C).

What I like with B is that is could be a first step for allowing more
control on the issue for the user (via Browntruck):
cf https://github.com/kubernetes/test-infra/blob/master/commands.md for
possible examples (so maybe allow to add a restricted list of labels).
Concerning the added complexity for contributors, PULL_REQUEST_TEMPLATE.md
could indeed be quite helpful.

The main issue is indeed that, when a contributor updates its PR and does
not post any message, nobody gets notified.
With option B, this is solved naturally since the user will have to post a
message, removing the "change needed" label but also triggering a new mail
notification :).

Concerning the failing tests, maybe Browntruck could also post a message to
tell the user that tests are broken (but I'm wondering if travis does not
already do that) if the tests are failing and the pull request has not been
updated since a day ?

Concerning the email digest, this seems like a good idea, weekly but not
daily.

Hopefully, with all this, we'll be able to merge PRs quicker which should
keep our list of open PRs fairly low and might help motivating new
contributors :)

Cheers,

-- 
Xavier